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 (that worked only in TLS 1.3 drafts but don'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 server-chosen part during 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 integrity isn't 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.