Remove unnecessary HTTP layer

The server currently uses an HTTP handler that expects a CONNECT method with a protocol of SSH3. ie. instead of GET / HTTP/1.0 it expects CONNECT / SSH3.

Current stack:

+------------------------------+
|          TLS / QUIC          |
+------------------------------+
|          HTTP Server         |
+-CONNECT SSH3-+-Other methods-|
| Shell Server | HTTP Server   |
+--------------+---------------+

That's easy to implement as a proof of concept, but the HTTP layer is unnecessary and makes it harder to multiplex a server (eg. as a web server and a shell server).

I propose that you could simplify the server and protocol by removing the HTTP layer. To do this, you would use these features of TLS:

• NextProto: Negotiate the application protocol (eg. shell-over-quic) during the TLS handshake (https://www.rfc-editor.org/rfc/rfc7301.html#section-3.1). This is supported in Golang via NextProtos in tls.Config: https://pkg.go.dev/crypto/tls#Config
• ServerName: Accept the server name during the TLS handshake (https://pkg.go.dev/crypto/tls#ConnectionState). This enables support for virtual hosts (https://github.com/francoismichel/ssh3/issues/43) and using the server as a proxy jump host.
• MTLS: Authenticate using client certificates, removing the complex code for parsing Authorization headers, JWTs etc. If you want complicated auth mechanisms (such as PAM support), you could negotiate those inside the shell-over-quic protocol.

Proposed stack:

+-------------------------------+
|             TLS / QUIC        |
+-NextProto SHH--+-NextProto H2-+
| Shell Server   | HTTP Server  |
+----------------+--------------+

This way the application protocol (Shell, HTTP, others) is made at the TLS termination point rather than at the web server layer, enabling easier integration with existing services.

If you've considered this already you may want to mention the trade offs in the docs.

Start by reviewing the current HTTP handler that expects CONNECT with the SSH3 protocol and the TLS/QUIC server setup. Compare the proposed NextProto, ServerName, and mTLS approach, then document the trade-offs; done means the application protocol no longer depends on the HTTP layer and the relevant documentation explains the design.