[Broker-J] Implement composite authentication provider

To make it possible to perform authentication either against the local
file-based database of users or against LDAP, as suggested in Qpid mailing list, new composite authentication provider should be developed. It should contain list of delegate authentication providers, which will be assessed one by one during authentication process until first successful authentication or until all authentication attempts fail. Supported delegate types could be implementations of UsernamePasswordAuthenticationProvider (MD5AuthenticationProvider, PlainAuthenticationProvider, SimpleLDAPAuthenticationManager, ScramSHA1AuthenticationManager and ScramSHA256AuthenticationManager).

As composite authentication manager will work with several user data sources and should support SASL interactions, it will be limited to authenticate client against first delegate containing authenticated username. I.e. when there are several delegates with users having same usernames but different passwords, it will be possible to authenticate client against the first delegate with the matching username.

Composite authentication provider should have property - "delegates", which will contain comma separated list of delegate authentication provider names.

Each delegate authentication provider has its own supported SASL mechanisms:

MD5 => ["PLAIN", "CRAM-MD5-HASHED", "CRAM-MD5-HEX"]
Plain => ["PLAIN", "CRAM-MD5", "SCRAM-SHA-1", "SCRAM-SHA-256"]
SCRAM-SHA-1 => ["SCRAM-SHA-1"]
SCRAM-SHA-256 => ["SCRAM-SHA-256"]
SimpleLDAP => ["PLAIN"]

Composite authentication providers will expose available SASL mechanisms of all configured delegates, but it should be considered, that depending on the delegate types configured, authentication process may require client to use "amqp.saslMechanisms" property for authentication.

Example:

Composite provider has 2 delegates: SCRAM-SHA-256 (contains user "scram-user") and SimpleLDAP (contains user "ldap-user"). When client establishes connection, most secure SASL mechanism is chosen, it will be SCRAM-SHA-256, meaning that scram-user will be able to authenticate and ldap-user will fail. To make possible for ldap-user to authenticate against SimpleLDAP provider, it would be necessary for client to specify "amqp.saslMechanisms=PLAIN" for ignoring SCRAM-SHA-256 mechanism and authenticate using PLAIN mechanism.

Another limitation is the possible name collision: when two delegate providers contain users with same names (but different passwords), it will be possible to authenticate only for the user defined in the delegate coming first in the list.

Example:

Composite provider has 2 delegates: Plain (contains user "test-user" with password "password1") and SCRAM-SHA-256 (contains user with same username "test-user" and different password "password2"). When test-user will try to authenticate using "password2" credential, it will fail (although username / password is correct in SCRAM-SHA-256 provider).

When using composite provider it should be avoided to configure users with same usernames in delegate providers. Usernames should be unique for all composite authentication provider delegates.