[tls] Track and check key schedule state

TLS already allows for several different paths to the establishment of
a shared secret channel.  The shared secret may be generated by the
client and encrypted using RSA key transport, or negotiated as a
Diffie-Hellman shared secret (via FFDHE or ECDHE), or mutually agreed
to be restored from a previously saved session resumption secret.

TLS version 1.3 defines several new paths to exist alongside these:
ephemeral key exchange is moved to the ClientHello and ServerHello
messages, server identity is verified using a CertificateVerify
message (instead of a signed ServerKeyExchange or an encrypted
ClientKeyExchange), and session resumption is handled via a new
pre-shared key mechanism.

While TLS version 1.3 in isolation is substantially simpler and
cleaner than earlier versions, the requirement to support both new and
old versions in the same code comes with a significant complexity
cost.

Guard against the possibility of future bugs by defining two
properties for the key schedule:

- a "keyed" flag indicating that the key schedule actually holds some
  shared secret key material (e.g. from ECDHE)

- a "bound" flag indicating that the shared secret key material in the
  key schedule has been bound to the identity represented by the
  server's certificate

These flags are updated when relevant key schedule events happen, and
validated before processing the server's Finished message.  If we
somehow end up receiving a Finished message without having established
and authenticated a shared secret, this check prevents us from marking
the connection as ready for application data.

Signed-off-by: Michael Brown <mcb30@ipxe.org>