Correlation issue in case of multiplex encryption for multiple recipients

The issue is closely related to #218 and #219, and is actually being discussed in the scope of #218 (see [comment](https://github.com/decentralized-identity/didcomm-messaging/issues/218#issuecomment-889145630)).
The issue seems quite fundamental and important so that it's worth creating a dedicated ticket and be reflected in the Spec.

It looks like there is a potential privacy disclosure and correlation issue if we use multiplex encryption for multiple DIDs (there is no issue to encrypt to multiple keys for one DID). A correlation is possible even if the sender ID is protected.
Example of multiplex encryption: [ecdh-1pu-04#appendix-B](https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04#appendix-B)
Please find the issue description below, and the options how we can deal with this.

## Issue
DIDComm supports protection of the sender ID (see #219 for details; it can be achieved by encrypting the `skid` or by calling anon+auth crypt). But if we want to send a message to multiple recipients (N-wise DID for example) and use multiplex encryption (as in [ecdh-1pu-04#appendix-B](https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04#appendix-B)) for multiple DIDs, then all target DIDs are open and not protected.
So, a mediator node (the one in front of final recipients) will know that all N DIDs have a connection after a number of exchanged messages.

**Example:**
- Alice wants to send a message to Bob and Carol via multiplex encryption. Alice builds and encrypts the message, and sends it to Bob's mediator and Carol's mediator.
- Bob's mediator sees Bob's DID and Carol's DID in the recipient list, so it concludes that **there is a connection between that DIDs.** The same for Carol's mediator.
- Then Bob wants to send a message to Alice and Carol via multiplex encryption. Bob builds and encrypts the message, and sends it to Alices's mediator and Carol's mediator.
- Carol mediator sees Alices's DID and Carol's DID in the recipient list, and this is the same Carol's DID as in the previous message. So, Carol mediator knows that **all three DIDs have a connection**.
- After a number of exchanged messages all mediators (the ones in front of final recipients) know that all three DIDs have a connection.

## Options how to deal with the issue

**Option 1: additional anoncrypt wrapping the message for the final recipient in case of multiplex-encryption for multiple DIDs**
It will hide the list of recipients from the Mediators, but it will require additional layer of encryption of the whole message breaking the whole point of multiplex encryption for multiple DIDs which we did to avoid additional re-encryptions of the payload.

**Option 2: do not support multiplex-encryption for multiple DIDs**
We should also probably make sender protection be enabled by default and recommended for most of the cases.
Pros:
- no obvious correlation issues (I don't say that there are no correlation issues at all, that needs to be analysed; but at least correlation is not as easy as in other options)
- less freedom for the user - less chances that user does something insecure or incorrect for his use case

Cons:
- have to encrypt the payload for every recipient DID. It can be quite bad if the message size is huge, however
- symmetric encryption operation is very fast (much faster than key agreement which we do a number of times for every message)
- it will not be very common to send huge messages. Huge messages are usually processed via stream-like API, but the current DID Comm spec and JOSE doesn't specify how to do this.
- [N-wise](https://identity.foundation/peer-did-method-spec/#features) mentions Multicast case, which will not be possible as-is.

**Option 3: do not support multiplex-encryption for multiple DIDs but support passing the same CEK**
It will be possible to use the same CEK (and hence do encryption of the payload just once) when need to send a message to multiple DIDs. In this case the message is encrypted just once with the same CEK for all the recipients, but then CEK is encrypted for every target DID separately, and the header has information about just 1 target DID. As a result, the same ciphertext is sent to every recipient (DID) separately.

Pros:
- less chances for correlation issues
- payload can be encrypted just once in case of multiple recipients

Cons:
- As the ciphertext is the same for all recipients, the correlation is still possible
- [N-wise](https://identity.foundation/peer-did-method-spec/#features) mentions Multicast case, which will not be possible as-is.

**Option 4: allow multiplex-encryption for multiple DIDs but only when sender is not protected**
The API should not allow to do multiplex-encryption for multiple DIDs when the sender is protected, but allows to do it when the sender is not protected.
DID Comm spec must provide very clear instructions what are cons and pros of using every method, and what are consequences and attack vectors.

Pros:
- If the user wants to keep privacy and avoid correlation, it's possible to do so by protecting the sender ID and encrypting the message separately for every recipient (see corresponding pros and cons of Option 2)
- If the user wants to do a multicast or do encryption for the payload just once for all recipients, it's possible to do it keeping the sender unprotected.

Cons:
- more freedom for the user, so more chances that the user does something insecure or incorrect for his use case
- not possible to do multicast or do encryption for the payload just once for all recipients and avoid correlation problems.