Dependency updates to eliminate vulnerabilities discovered by dependency-check

See merge request !36

updating language in README.md

See merge request !35

correcting repository ID so that it uses the correct authentication, adding...

See merge request !34

Changes to migrate deployment to gitlab,adding gitlab-ci file

See merge request !33

Migrate_Deployment: Migrating deployment to gitlab, also removing dependencies on external com.gitlab.nblair repo in favor of local gitlab copy of adi-development library

Switch to open releases proxy for distribution

See merge request !32

Switch to snapshot version to release with mvn plugin

See merge request !31

Update Spring to Latest Version

See merge request !30

Test Cleanup

See merge request !29

Adding display name attribute, updated UDS libraries

See merge request !27

Setting UwframeSession to use fullName as display name if displayName is null. Previously always used fullName, but recent commit set it to always use displayName. This commit splits the difference.

Upgraded UDS services libraries to newer uds-person-client-java 2.0, and the 1.2 data model that includes access to preferred name. Also added displayName attribute to UWUserDetails that should be picked up from Shibboleth displayName header

deprecate: LocalUserDetailsAttributesMapper

I'm preparing a 1.7.0 release, thought I'd stick this in there as well.

See merge request !26

Use LocalUserDetailsLoader instead.

refactor: change injection strategy for UdsPersonUserDetailsServiceImpl

`UdsPersonUserDetailsServiceImpl` is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).
    
 Registering more than 1 `UserDetailsService` - say one for the uw-spring-security stack, and a different one for `UdsPersonUserDetailsServiceImpl` - will result in ApplicationContext initialization errors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.
    
The recommended use now for `UdsPersonUserDetailsServiceImpl` is to provide the needed `UserDetailsService` by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.

See merge request !25

Change to UdsPersonUserDetailsServiceImpl construction necessitates.

UdsPersonUserDetailsServiceImpl is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).

Registering more than 1 UserDetailsService - say one for the uw-spring-security stack, and a different one for UdsPersonUserDetailsServiceImpl - will result in ApplicationContext initializationerrors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.

The recommended use now for UdsPersonUserDetailsServiceImpl is to provide the needed UserDetailsService by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.