DID:peer:4 support and community coordinated update strategy

Step 1:
- Support DID Exchange Requests coming from any algo (1, 2, 4). Respond with a did:peer matching the one received
- Add a Discover Features automation that allows for requesting a selected number of features automatically. By default it will ask for did:peer:2 / did:peer:4 support
- Add option to choose default did:peer algo for DIDExchange Requests. If not defined, it will be did:peer:1. There will be NO option for unqualified DIDs
- Connection Requests: it will be left as it is now (unqualified DIDs)
- ConnectionRecord will probably need to add a field where the “DID for exchange” will be defined (if different from the internal did, which I guess it should be did:peer:3)

Step 2:
- Default DID Exchange Requests to use did:peer:4. Optionally we can take this opportunity to also support did:peer:2 and public DIDs
- Would a fallback mechanism be needed? (e.g. try first with peer:4, then peer:1)
Step 3:
- Default DID Exchange Requests to use did:peer:4

## Notes from WG call (17-08-2023)

- We are not going to support unqualified dids for DID Exchange, we will only support qualified dids
- We are not going to support qualified dids for Connection protocol, we will only support unqualified dids
- it should be doable to support did:peer:2 in did exchange.
- if we have did:peer:2, there is not attachment that can be signed.
- We need a solution for this: https://github.com/hyperledger/aries-rfcs/issues/717
- Add information to the RFC how to handle a resolvable did, but also include a signature
- Do a follow up of https://github.com/hyperledger/aries-rfcs/pull/725 ?
- in terms of protocols we should support did:peer:2 in did exchange
- downside of using did:peer:3 => field where the “DID for exchange” will be defined

## Update on 14-09-2023
- RFC 0793 has been updated to replace did:peer:2/3 by did:peer:4. It also now mentions DID Rotate protocol