Specify padding and context strings for signatures

The TLS 1.2 ServerKeyExchange signature never included enough context
and it was possible to lift a signature for one ciphersuite into a
handshake for a different one. TLS 1.2 only avoided signature
repurposing attacks because of luck[1].

Additionally, TLS 1.2 allows an attacker to obtain a signature of a
message with a chosen, 32-byte prefix.

Because of this, this change causes TLS 1.3 to include 64 bytes of
padding at the begining of signed messages in order to easily clear the
chosen-prefix and also context strings to ensure that signatures cannot
be repurposed.

For more context, see
https://www.ietf.org/mail-archive/web/tls/current/msg14734.html

[1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf
Have CertificateVerify sign a hash of the messages

Once padding and context is introduced into the signatures, it's no
longer possible for a single running hash to be used for both
CertificateVerify and Finished processing. That might cause
implementations to have to keep multiple running digests.

This change causes a hash of the messages to be signed instead, which
solves the problem. If we are using the hash for a signature then we
already depend on its second-preimage resistance in any case.
Change handshake_hashes for CertificateVerify to be the PRF hash
Trivial editorial from AGL
Merge pull request #110 from ekr/issue100_context_strings

Issue100 context strings