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...
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.
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/