Fix a regression in #224: the context may have no replacer

[vnxme]

This PR fixes the panics caused by the tls alpn matcher as reported in #259. The fix is a copy of caddyserver/caddy@7cf8376 we merged into the mainline for the tls sni matcher a few month ago.

[mholt]

Thanks -- kind of unfortunate we can't reliably know there's a Replacer available. Do we know if it's rather possible to ensure a Replacer is always in the context? I wonder if that would be easier than ensuring every handler/matcher does this check.

[vnxme]

Well, my understanding is as follows:

• As fairly mentioned here, the tls app matchers only accept tls.ClientHelloInfo. We do have a valid replacer in a layer4.Connection, but we can't pass it through.
• Given we fill the tls.ClientHelloInfo here, I expect its ctx field to always equal nil, since we don't assign any value to it because it isn't exported.
• I assume we don't use this alpn matcher in the mainline code, but if we did, its ctx field would most probably have a valid replacer since we pass the app context to the tls.Config (unless we fake a real connection in tests, e.g. caddytls.TestServerNameMatcher).

So I would conclude that:

• For layer4 purposes tls.ClientHelloInfo doesn't have a context, that's why we create a new replacer;
• For mainline purposes (if we use this matcher anywhere else) tls.ClientHelloInfo will have a context, and we try to reuse the existing replacer, if any.

[mholt]

Good points. Thanks for this patch.