Don't construct `EncodedMessage` in `MessageEncrypter`, `MessageDecrypter` impls

Checklist

• I've searched the issue tracker for similar requests

Is your feature request related to a problem? Please describe.
Each implementation of trait MessageEncrypter in a crypto provider implements the function:

    /// Encrypt the given TLS message `msg`, using the sequence number
    /// `seq` which can be used to derive a unique [`Nonce`].
    fn encrypt(
        &mut self,
        msg: EncodedMessage<OutboundPlain<'_>>,
        seq: u64,
    ) -> Result<EncodedMessage<OutboundOpaque>, Error>;

As a result, each crypto provider must make a decision about what content type and protocol version to put in the returned EncodedMessage<OutboundOpaque>. Some of them copy the content type and protocol version from the input msg, but some of them force those values to ContentType::ApplicationData and ProtocolVersion::TLSv1_2, respectively.

The correct content type or protocol version to emit has nothing to do with which crypto implementation is in use, so this interface seems to unnecessarily introduce an opportunity for providers to make mistakes.

Symmetrically, we have trait MessageDecrypter:

    fn decrypt<'a>(
        &mut self,
        msg: EncodedMessage<InboundOpaque<'a>>,
        seq: u64,
    ) -> Result<EncodedMessage<&'a [u8]>, Error>;

TLS 1.2 implementations ignore everything in msg except the payload, while TLS 1.3 implementations have to remember to use EncodedMessage::into_tls13_unpadded_message.

Describe the solution you'd like
If the interface were changed to take bytes of plaintext instead of EncodedMessage<OutboundPlain> and return bytes of ciphertext instead of EncodedMessage<OutboundOpaque>, then the calling context (crypto::cipher::record_layer::EncryptionState::encrypt_outgoing) could take responsibility for correctly constructing records no matter what provider is in use. So perhaps change the trait method to:

fn encrypt(&mut self, plaintext: &[u8], seq: u64) -> Result<Vec<u8>, Error>;

Or if we consider the proposition in #3068 and the broad push toward client owned buffers, then we could do decryption in-place and avoid allocating:

/// `payload_len` is <= `payload.len()` and is where the plaintext ends. Caller is responsible for ensuring that `payload` is big enough for the ciphertext (e.g. enough room for AEAD tag and padding).
fn encrypt(&mut self, payload: &mut [u8], payload_len: usize seq: u64) -> Result<(), Error>;

Symmetrically, MessageDecrypter could do:

fn decrypt(&mut self, ciphertext: &[u8], seq: u64) -> Result<Vec<u8>, Error>;
//or in-place:
fn decrypt(&mut self, ciphertext: &mut [u8], ciphertext_len: usize, seq: u64) -> Result<(), Error>;

Additional context
Another issue discussing changes to this interface: https://github.com/rustls/rustls/issues/3068

Start with the MessageEncrypter and MessageDecrypter traits and the crypto::cipher::record_layer::EncryptionState::encrypt_outgoing entry point. Compare the provider implementations to see how EncodedMessage metadata is currently handled, then read issue #3068 before choosing between returned buffers and client-owned in-place buffers. Done means the interface and callers leave record construction to the calling context consistently across providers.