The QUIC protocol of the future is the one that is being standardized by the
IETF *right now* and is planned to get done by the end of this year. Adding
support for Google's old (current) version of QUIC has much less value for the
future (in my opinion).

I think all the requests should use TCP by default unless explicitly told
to use QUIC by some flag. If we get "Alternate-Protocol: 123:quic"

The Alt-Svc header tells the client that the service exists somewhere else,
possibly using another protocol (like HTTP-over-quic, hq), so yes.

in response header we should inform the user, close TCP connection and use
QUIC instead.

*Ideally* you'd try to setup the QUIC connection in the background or in
parallel since it may not work and then it is a good idea to keep using the
initial TCP connection...

It isn't specified formally on wiki page, but I think we should be able to
communicate with HTTP using QUIC protocol. Is there something more to it?

You might learn that the implementations are not yet 100% there, so speaking
full HTTP over QUIC is a bit shaky but should be in a better shape by the
summer. (Most implementations so far have stuck to "HTTP/0.9" over QUIC for
simplicity and early interop, but this situation will of course not last.)