Fix AliasX509ExtendedKeyManager to process both server and client aliases properly

[ecnabogs]

SpringBoot provides a default implementation of the org.springframework.boot.ssl.SslManagerBundle interface (DefaultSslManagerBundle) that allows to specify a SslBundleKey (referencing the private key within the associated KeyStore) to be used for establishing an SSL connection. This feature, added in SpringBoot 3.1.0, is really appreciable as it simplifies a lot the selection of the private key to be used during SSL handshake.
However, the thing is that the underlying implementation (AliasX509ExtendedKeyManager) only considers the server-side of an SSL connection. If a client has to communicate with multiple partners through mTLS protocol and has a single KeyStore containing its private keys, it cannot select the appropriate key alias to be used with the related partner.

My proposal is to support this use case and to make AliasX509ExtendedKeyManager working similarly for both server and client sides. That's the first point.

Then, looking more in details at the implementation, I noticed that the selected alias was returned unconditionally at the server side. I think it is not correct as SSL handshake is expected to reach an agreement between client and server, especially regarding the key algorithm to be used. Here, this algorithm is not taken into account meaning that although the key with the specified alias could exist in the underlying KeyStore, it could also be of the wrong type.
Thus, my implementation gets inspired by the JDK default implementation (sun.security.ssl.SunX509KeyManagerImpl) in which the alias selection is made by calling the getServerAliases(keyType, ...) or getClientAliases(keyType, ...) for restricting the choice to compatible keys only.

Finally, the AliasX509ExtendedKeyManager current implementation also only considers the transport-independent SSLEngine but not the Socket-specific one. To cover all use cases, the implementation should also apply the same alias selection logic to the Socket-specific methods. That's what I did actually and factorized this logic for all contexts.