Add support for minor version handling

[swcurran]

In aries-rfcs issue 407, it was agreed that there were rules that frameworks should support around the handling of minor versions of a protocol:

1. Minor versions can only include the addition of new fields and the continued semantic meaning of existing fields. When a change violates those conditions, a new major version is required.

2. An Aries agent should be able to handle the receipt of any minor version within a single major version above the one they implement and any minor versions below that they want to support. E.g. an agent that handles the 1.3 message should be able to handle any 1.3+ message, and 1.0, 1,1 and 1.2 if they want to. On backwards compatibility - generally they would support the earlier minor versions unless there is a good reason not to, e.g. a feature in HTTP 1.1 (keep-alive) that is not supported in HTTP 1.0, and hence unusable for that use case.

3. We'd like by default that ACA-Py support all minor versions of a major protocol version. We should add a controller mechanism that tells ACA-Py to respond with a "Not Supported" problem-report.

4. Any fields not recognized in a message must be silently ignored. Thus, an agent that supports version 1.3 can receive a 1.5 message and process it using the 1.3 handling, ignoring any added v1.4 and v1.5 data items. Of course, that also means ignoring fields incorrectly put into the message.

5. If an agent chooses to respond to a discover feature message, the agent should respond with the latest version that the agent fully supports (e.g. 1.3 in the previous example).

6. Likely already done in ACA-Py, but this should be confirmed.

7. When sending a response, an Aries agent should always respond with the latest version of the message that it supports.

8. Again, likely already done, but should be confirmed.

9. ACA-Py should be capable of sending back a problem-report if a message of an unsupported major version is received, with options for the controller to activate (or not) that protocol. For now, we should make this an all or nothing feature, but it if it is easy, implement a protocol-by-protocol config, including an "unknown protocol" configuration.

This issue will be converted to an epic at some point with specific issues added to address smaller chunks of the work.