Allow client to use standard (non-early) exporter for channel_binder

[artoniemi]

The early exporter value depends only on the ClientHello contents and on the (possible) PSK. If there is no PSK, then it depends only on the ClientHello and is therefore not secret.

For the client, we can get better replay/relay protection by using the a standard exporter value (dericed from exporter_master_secret).

Propose something like:

The channel binder (channel_binder) is a value obtained from the exporter mechanism offered by the TLS implementation. If the exporter_master_secret can be computed at the time of evidence generation, then the implementation SHOULD TLS-Exporter API to derive the exporter value. Otherwise, the implementation SHOULD use the TLS-Early-Exporter API.

(For the server, we could also consider allowing using Carstens channel binder construction: transcript hash concatenated with the ECDHE shared secret, but implementing that requires a bit more extensive hacking of the TLS library).

[thomas-fossati]

As discussed in Madrid:

• Client uses TLS-Exporter.
• Server uses a transcript hash covering CH, SH and EE. (The trouble here may be that implementations do not provide the mechanics off the shelf and we need to implement it by hand.)

[thomas-fossati]

Also, Arto noted that Figure 8 does uses CBOR to define the binder. We should change it to use the TLS presentation language instead.

[ionut-arm]

A new suggestion for this has been put forward recently (see here). The short version is: instead of defining a way to extract the transcript hash, it's easier and more consistent to define a new exporter interface; it would be available after ServerHello, and would thus cover our needs, and be suitable for use by both server and client.

Also see #60