Add TLS 1.3 cert support in --banner

[gpotter2]

This PR adds TLS 1.3 support for --banners and certificate retrieval. For context, this is a bit harder than on TLS 1.2 considering the server certificate is encrypted.

Changes:

• Support TLS 1.3 certificate retrieval in masscan.
• Properly detect TLS 1.3 by checking the supported_versions extension instead of the announced tls version (using the main version field worked only in TLS 1.3 drafts and doesn't in the final spec)
• Add proper testing of everything added with real-life TLS1.3 exchanges.
• Added a note regarding the various licenses included in massacan. It's worth keeping track of

Some notes regarding the implementation:

• I tried to stay as close as the "masscan spirit" as I could: dissection can happen byte by byte, the only buffer (if required) being the 16 octets required for an AES block (so that if the incoming bytes don't fall on a round block, it still works).
• The only supported algorithms combo is X25519 with AES256-GCM. The reason for chosing X25519 over other ones is that it's mandatory per RFC8446, but also because it's the only one supported by OpenSSL before version 3.0, so it should increase compatibility.
• I understand that masscan tries to be dependency-less. This therefore brings several open (and that looked trustworthy enough) crypto-related implementations for the various parts of the exchange. I chose those mostly to be license-compatible with masscan.
  • AES 256 (with a single addition: a function to increase the CTR counter)
  • X25519
  • RFC6234 standard implementation of TLS 1.3 HKDF mechanisms
• I chose performance over anything else: the crypto implementation is fundamentally unsafe
  • Everything in the TLS 1.3 exchange that could be hardcoded was hardcoded. The client part of the diffie-hellman key exchange is therefore always the same, so beware that exchanges aren't actually private..
  • In the AES-256 GCM implementation, we discard the authentication tag for performance. This means that integrity isn't actually checked.

Caveats:

• I have only one concern over the current implementation: TLS 1.3 requires a few fields, most notably the negotiated master keys, to be added to the StreamState. I haven't really checked what impact this would have on the memory footprint, but it could be a bit important. It's possible to work around this by malloc()'ing a separate TLS state only when required, but I was a bit scared to add some complexity regarding memory management. It's still an option if deemed appropriate

Note that this PR would allow to support sending probes over TLS with minimal effort. I think it's best to have this first part merged though before adding more complexity.