[#2132] Migrate SSL support away from ThreadLocal, support key alias and default to pkcs12

[mattrpav]

All wiring of transports now takes SslContext as a parameter, instead of 'magically' showing up as a ThreadLocal when needed.

This unlocks a lot of capabilities, including per-transportConnector SSLContext, per-networkConnector SSLContext and eventually auto-reloading of SSLContext.

• DefaultSslContext (remove active usage of ThreadContextSslContext)
• Default to stronger and now JDK-default keystore type: 'pkcs12'
• Add support for keyAlias
• Add per-connector sslContect
• Add per-networkConnector sslContext
• Add ComptibleSslContext to bridge Spring for a non-ThreadLocalSslContext
• Retain a ThreadContextSslContext class in case someone extended some part of the broker or client (add'l transport connector, etc) and needs a way to transition
• Unit test refactors

Merge plan: Squash all commits to one for v6.3.0 only (no backport)

[cshannon]

This is a pretty major refactor and needs to be reviewed carefully before merging. I assume this will not be backported and only be targeted for 6.3.0 due to the major changes.

@mattrpav - are there breaking API changes here? a quick look showed old methods delegating to the new ones so I don't think so but we don't want to break anyone who upgrades

[mattrpav]

@cshannon correct, this is only for 6.3.0.

The original SslContext is renamed ThreadLocalSslContext and remains if anyone needs previous behavior exactly.

The ComaptibleSslContext provides same method signature as the ThreadLocalSslContexr for historical compatibility for wiring of arrays v lists, but removes the ThreadLocal usage.

The DefaultThreadLocalContext becomes the new default.

This change removes all ThreadLocalSslContext usage and updates transportConnectors and networkConnectors to support having independent SSLContexts as needed. They all fall back to the broker-wide one as before, if an independent sslcontext is not configured.