Support a better interface to matching rules

[rholshausen]

Not having to create our own content type to add metadata to contracts. We have had to make the "application/json" content matcher again so that we can add metadata fields into the contract. This means that we have had to find the core implementation of application/json and copy bits of code to keep the same behaviour and then try to add the metadata on top.
Easy to use / documented core library and utility functions for matching. For example a function we can call with a JSON message payload and a pact and find which contract is the best match. Currently we have pieced together bits of pact_matching with our own transformations from a JSON message and some metadata to match websocket messages as they come in. We also reimplemented the loop that goes over the contract and calls the comparison for each one. This process feels like it could be a bit easier for plugin developers if they want a consistent and out of the box feel for the plugin behaviour.

Currently, plugin authors either have to write their own matching rules, or use an existing implementation from one of the Pact implementations. The Pact implementations have not been designed to export this functionality for external use, so it requires knowing the internals to the Pact implementations and the capability will be different between different language implementations.

[github-actions]

👋 Hi! The 'smartbear-supported' label has just been added to this issue, which will create an internal tracking ticket in PactFlow's Jira (PACT-1136). We will use this to prioritise and assign a team member to this task. All activity will be public on this ticket. For now, sit tight and we'll update this ticket once we have more information on the next steps.

See our documentation for more information.