feat(ocpp-wamp): terminate TLS on the WebSocket server for security profiles 2 and 3 #155

Context

Security profiles 2 and 3 of OCPP (OCPP 1.6 Security Whitepaper edition 3, OCPP 2.0.1 part 2 §A00) secure the
connection with TLS, the CSMS acting as the TLS server (A00.FR.306, A00.FR.409). Profile 3 also authenticates the
charging station with a TLS client certificate (A00.FR.401, A00.FR.402).

The WebSocket server of ocpp-wamp only opens a plain HTTP listener: Undertow.toServer calls addHttpListener
(source),
and nothing in the toolkit takes an SSLContext.

Problem

• Profiles 2 and 3 only work behind a reverse proxy terminating TLS.
• The ConnectionAuthorizer of feat(ocpp-wamp): admit a charging station from the headers of its upgrade request #152 (feat(ocpp-wamp)!: admit a charging station from its upgrade request headers #154) cannot see the client certificate of a profile 3 station. Behind a proxy,
  the certificate only reaches the toolkit through a header the proxy adds, whose name is not standard and which the
  application has to trust.
• The TLS rules depend on the version: TLS 1.2 or above, but an OCPP 1.6 charge point MAY use TLS 1.0 or 1.1 while
  OCPP 2.0.1 forbids them (A00.FR.416), and the specifications list the cipher suites a CSMS must support.

Proposed solution

• An HTTPS listener for Undertow, OcppWampServer.asServer and the toolkit ServerSetting, built from an
  SSLContext the application provides, so that the key material stays with the application.
• Client authentication requested rather than required, so that stations of profiles 2 and 3 can share a port and the
  decision stays with the authorizer.
• The verified certificate chain of the station exposed on ConnectionRequest, which feat(ocpp-wamp)!: admit a charging station from its upgrade request headers #154 made a class for that
  purpose.

To settle: the TLS versions and cipher suites the toolkit enforces versus what it leaves to the SSLContext, and
whether the certificate forwarded by a TLS-terminating proxy is supported, for instance through an opt-in trusted
header.

Acceptance criteria

• A CSMS can serve OCPP-J over wss:// from an SSLContext it provides, with ocpp-wamp alone and with the
  toolkit.
• The client certificate chain of a station reaches the ConnectionAuthorizer through ConnectionRequest.
• A station without a client certificate can still connect when the authorizer allows it.
• Tests cover a wss:// connection with and without a client certificate.
• The README shows how to enable TLS.

Out of scope

• Checking the certificate (certification path, O and CN of its subject) and enforcing a security profile: see feat(ocpp-wamp): enforce the security profile expected for each charging station #156.
• The certificate management messages, already exposed by [REQUEST] Add support of OCPP 1.6 - Security whitepaper #90.
• Storing and rotating the certificates, which belongs to the application.