refactor(core): alpha.7 rewrite

[sinui0]

This PR completely rewrites tlsn-core for our alpha.7 release. Closes #438

There are still a couple of loose ends that I'm tidying up but the vast majority of the deliverable is there. Prior to accepting this PR we will need to review our new fork of rs_merkle which was required to support hash algorithm customization.

A follow up PR will be provided which completes the integration of these changes into the other crates. I have most of this integration work complete on a separate branch already.

Highlights

• Improved the structure of attestations
  • Header has a static smol size and now includes a version tag and unique identifier
  • Body fields are now merkelized so that only fields necessary to prove desired statements need to be included
  • Body is forward-compatible with new kinds of fields (for example, new kinds of commitments)
• Added a Request pattern which will allow a Prover to configure aspects of the attestation depending on what the Notary supports.
  • This paves the way for custom extensions, eg #342
• Further encapsulated various kinds of proofs
  • ServerIdentityProof proves the server name using the certificate chain
  • AttestationProof proves the Notary signature and attestation body
  • TranscriptProof proves subsequences of the transcript using the encoding or hash commitments.
• Extensible cryptographic algorithms via CryptoProvider (inspired by rustls).
  • Supports multiple hash algorithms, including user provided custom.
  • Supports multiple signature algorithms, including user provided custom.
• Added a new PlaintextHash commitment type (not fully exposed yet) which will be implemented with authdecode. See #479
• Encapsulated more logic into this crate in the form of builders, reducing API surface area and making it more difficult to misuse. There should now be very little implementation code in prover and verifier crates related to attestations.

Not Included

There are some items that I initially wanted in scope but decided to remove as they proved to be larger than anticipated.

• Protobufs
• Canonical serialization format which is efficient to implement in the EVM. For now we continue to use BCS which uses varint encoding. This may actually be ok, but I've not looked into it.
• Extensive versioning
• #342
• #351