Related: tpo/anti-censorship/team/-/issues/86

To match documentation added in
7aa47e7f.

The crypto/tls server, since go1.12, requires that if a server_name
extension is present, it is not empty. With go1.12 and later, this test
was failing with
	proxy_test.go:95: local error: tls: unexpected message

The specific commit that added the empty server_name check was:
https://go-review.googlesource.com/c/go/+/144115
https://github.com/golang/go/commit/4c8b09e9183390d6ab80d3f53a9fe5f6ace92f06#diff-f2f5faeac5da94dc7735456f798177b53421f827b8bfc242b56f116b8e5c7e62R264
Note the comment "enforcing a couple more 'must not be empty' on the
unmarshaling side".

Wireshark also complains in a packet capture:
	[Expert Info (Warning/Protocol): Vector length 0 is smaller than minimum 1]

https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/meek/40002

This ought to have been removed in
bc887de6.

https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/meek/40002

github.com/refraction-networking/utls

Adds
	HelloFirefox_65
	HelloChrome_72
	HelloIOS_12_1

Clone is new in go1.13.
https://github.com/golang/go/issues/26013

https://bugs.torproject.org/29611#comment:6

https://bugs.torproject.org/29611

app.update.enabled doesn't exist anymore:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420514

This is copied from
projects/tor-browser/Bundle-Data/PTConfigs/meek-http-helper-user.js in
tor-browser-build.git commit 4792ed5246d389caad036290e9ed34ff0ae1f0ad.

The difference here is that we don't send a JSON error response as a
result of errors at this stage.

The native component actually doesn't need to introspect the objects it
passes to the browser, except for the "error" property of a response
when it wants to report its own error.

Re-use the catch handler.

This doesn't hurt, but we're still reliant on Firefox for using the
global "browser" object (instead of "chrome"), and especially for the
proxy code, which has a totally different API in Chrome.

A typo during debugging caused the callback to crash and have no effect.

The WebExtension needs a JSON "host manifest" that both authorizes the
extension to run a native executable, and tells the browser where to
find the native executable. The path inside the manifest needs to be an
absolute path, so we cannot just plunk down a static file; we have to
know the path to where the browser is installed. meek-client-torbrowser
rewrites the manifest on each startup, where the browser expects to find
it.

The is mostly self-contained and compatible with previous behavior, with
one small exception on windows. On mac and linux, the browser expects to
find the manifest in a well-known location (relative to $HOME, which in
our case is inside the browser's directory tree or the ancillary
TorBrowser-Data directory). But on windows, the path to the manifest
needs to be stored in the registry. So meek-client-torbrowser not only
writes the manifest file, it also writes a registry key pointing to the
file. I'd like to try and find a way to do this that doesn't require
modifying global state like this.

This patch is tested on linux and windows but not mac.