Make it possible to enable / select an existing User Directory Provider without rebuilding source

Closing subtasks for 2.5.0 release.

Merged from https://sakaiproject.atlassian.net/browse/SAK-10418#icft=SAK-10418 working branch -r34663 to trunk at revision: 34683.

The next step is to start cleaning up the "providers" module to enable out-of-the-box UserDirectoryProvider implementations. For a provider to be safely deployed the following must be true:

1. The provider ID should be specific to the implementation. (Just making it the same as the class name should suffice.)

2. The provider bean must be configured with 'lazy-init="true"'.

3. The provider must be completely configurable via sakai.properties.

I added "setProviderName(String userDirectoryProviderName)" to the BaseUserDirectoryService, defaulted it to "org.sakaiproject.user.api.UserDirectoryProvider", and use it (if non-null) to load the provider at init time. Here's what that means in terms of functionality:

• It doesn't effect current deployment configurations. By default, there's no UserDirectoryProvider active out of the box. If an installation already has deployed a component WAR with the ID "org.sakaiproject.user.api.UserDirectoryProvider", it will continue to be used as the active UserDirectoryProvider. If an installation is programmatically injecting a provider, that will also continue to work.

• A provider with a different ID can be chosen through sakai.properties:

providerName@org.sakaiproject.user.api.UserDirectoryService=org.sakaiproject.provider.user.FilterUserDirectoryProvider

• Or an existing provider can be disabled through sakai.properties by setting the name to the empty string:

providerName@org.sakaiproject.user.api.UserDirectoryService=

I checked this into the https://sakaiproject.atlassian.net/browse/SAK-10418#icft=SAK-10418 working branch as revision: 34638. (Although since it's backwards-compatible, it should be safe to move into trunk separately from the other changes.)

This should be simpler to manage than https://sakaiproject.atlassian.net/browse/SAK-10057#icft=SAK-10057 was.

The CourseManagementService needs to be directly discoverable and injectible by code in a bunch of different modules, and so a fairly natural way to do that was to proxy the runtime-selected implementation with a stable bean name.

As far as I know, though, only the UserDirectoryService component needs to know what the current UserDirectoryProvider is. We only have to worry about controlling a single setter in a single bean.