Add TLS 1.3 fix and testcase.

It turns out that Chrome supports an experimental mode to support TLS
1.3, which uses a non-standard way to negotiate TLS 1.3 with a server.
This non-standard way to negotiate TLS 1.3 breaks the current draft RFC
and re-uses an extension on the server-side with a different binary
formatting, causing us to throw a binpac exception.

This patch ignores the extension when sent by the server, continuing to
correctly parse the server_hello reply (as far as possible).

From what I can tell this seems to be google working around the fact
that MITM equipment cannot deal with TLS 1.3 server hellos; this change
makes the fact that TLS 1.3 is used completely opaque unless one looks
into a few extensions.

We currently log this as TLS 1.2.

testing/btest/scripts/base/protocols/ssl/tls13-experiment.test

@@ -0,0 +1,16 @@
+# @TEST-EXEC: bro -C -r $TRACES/tls/chrome-63.0.3211.0-canary-tls_experiment.pcap %INPUT
+# @TEST-EXEC: btest-diff ssl.log
+# @TEST-EXEC: btest-diff .stdout
+
+# This is a trace that uses a completely non-standard way of establishing TLS 1.3; this seems
+# to be an undocumented extension where the TLS version is negotiated via the server sending back
+# an supported_versions extension (which, according to the RFC is strictly prohibited).
+#
+# This only seems to happen with Chrome talking to google servers. We do not recognize this as
+# TLS 1.3, but we do not abort when encountering traffic like this.
+
+event ssl_extension(c: connection, is_orig: bool, code: count, val: string)
+	{
+	if ( ! is_orig && code == 43 )
+		print bytestring_to_hexstr(val);
+	}