FR: nested network filter chains

Currently, listener inspectors and transport sockets are forced to reside at one-level: first inspect, then match, then use a transport socket. This is quite inflexible, and leads to situations where a whole expensive listener is needed (e.g. https://github.com/envoyproxy/envoy/issues/4076). The proposal is to add a oneof that allows (inspectors + filter chains) to reside within the filter chains next to filters. The semantics is that processing is staged where once a filter chain is selected, transport socket is applied, and then inspector + filter chain matching restart.

This solves a bunch of issues:
1. Proxy protocol can be placed within TLS on server-side.
2. TLS-within-TLS can be matched provided outer TLS is prior knowledge.
3. HTTP-within-TLS can be sniffed provided outer TLS is prior knowledge.