router: Future-Proof Non-HTTP actor protocols

# Motivation
atenet router's primary function is to receive an incoming request, parse the actor and ate space name from the Host header, and resume the actor before forwarding the request to the worker IP hosting that actor. While this is currently HTTP-only, the current hostname-style addressing scheme leaves open the possibility of supporting non-HTTP actor protocols by using TLS (the router uses SNI to parse the `atespace:actor` tuple). Even this has issues though as it's not possible to front a single wildcard TLS certificate for actors as the DNS name has two wildcarded components (*.*.actors.resources.substrate.dev). In order to pave the way for HTTP-specific actor addressing schemes (e.g. paths or headers), this issue proposes a strategy to support actors with non-HTTP protocols.

# Proposal

Substrate ingress standardizes on HTTP, HTTPS, and HTTP/2 (TLS and h2c) as the supported transports for calling an actor. Clients will explicitly dial the ingress load balancer (likely via a DNS name provisioned out-of-band) since the encoding will occur outside of the host header (exact shape tbd; we can discuss in #445). To support actors that don't speak HTTP, the ingress must support terminating CONNECT and forwarding the opaque TCP packets from tunnel. In this model, the ingress will be able to have a single parsing scheme for determining the atespace;actor tuple regardless of actor protocol.

Happy to take a stab at POCing this if we think it's a good idea