Research PSK/session resumption in TLS 1.3

QSslSocket supports client-side session resumption using session tickets. According to RFC 8446, 2.2, this
mechanism considered to be obsolete in TLS 1.3, there session resumption changed. In TLS 1.3 it's more like
PSK and session resumption merged into one thing:

Once a handshake has completed, the server can send the client a PSK
identity that corresponds to a unique key derived from the initial
handshake (see Section 4.6.1). The client can then use that PSK
identity in future handshakes to negotiate the use of the associated
PSK. If the server accepts the PSK, then the security context of the
new connection is cryptographically tied to the original connection
and the key derived from the initial handshake is used to bootstrap
the cryptographic state instead of a full handshake. In TLS 1.2 and
below, this functionality was provided by "session IDs" and "session
tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.

Since Qt 5.15 supports TLS 1.3 by the means of its OpenSSL backend It makes sense to investigate if any
new public API is required to use/enable this feature.

PSK mechanics also changed in TLS 1.3(which was overwhelming some of our PSK auto-tests in the
past, when we first got OpenSSL 1.1.1). RFC 8446, 2.3 describes so called 0-RTT data, when a client
sends PSK (either obtained 'out of bound' or via the previous handshake/session in the 'first flight'.
Again, good to check if any new public API must be introduced in 5.15.

We start with OpenSSL backend since it's our only backend supporting TLS 1.3 and we already know SecureTransport
will never do (fortunately, SChannel seems to be more alive and will eventually officially get TLS 1.3).