HTTPS is layered such that it's HTTP > TLS > TCP.
QUIC replaces the 'TLS > TCP' portion with 'QUIC > UDP', which you can then run HTTP or HTTP2 on top of.
QUIC is not an alternative to HTTP2 (yet), although there's work underway to (re-)define HTTP2 in terms of QUIC [1], thereby replacing the awkward transport protocol aspects of HTTP2 with the very similar mechanisms provided by QUIC.
[1] https://tools.ietf.org/html/draft-shade-quic-http2-mapping-0...
For those seeking more detail, I found these two links helpful:
https://docs.google.com/presentation/d/15e1bLKYeN56GL1oTJSF9...
https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...
You could use QUIC to transport other L7 protocols, but tracking down generic-enough implementations may be difficult, or at least was the case in the past [1][2]. Maybe things are better now [3].
[1] https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/
Have not looked into that QUIC mapping yet, but I have read that generic use is a goal for it, which is good. If HTTP over QUIC succeeds (it probably will if pushed by google) I'm wondering how of how much use HTTP/2 still will be. Classical HTTP will most likely always exist as it's easy to implement and is covered by lots of systems (even embedded) and libraries.