RFC: Replace cgo with ebitengine/purego

[YOU54F]

Rationale

since pact-go v2 was created, we rely on functionality from a rust shared core, which is delivered by way of C shared library, and is loaded via FFI (Foreign Function Interface) via cgo, into pact-go.

This has meant that users have to explicitly enable cgo, and those who cannot install or do have a c compiler installed, have been unable to use pact-go v2.

See #321 for a related issue.

Alternatives

1. Rewrite pact-go in purego (not unfeasible, but highly undesired, and moves away from a single shared core mantra)
2. Leverage ebitengine/purego - A library for calling C functions from Go without Cgo.

Leveraging ebitengine/purego

Options

1. Utilise ebitengine/purego in CGO_ENABLED=0 mode only
2. Retains standard cgo behaviour owned by the go team
3. ebitengine/purego is in beta, so this uses a cautious approach
4. Utilise ebitengine/purego in both CGO_ENABLED=0/CGO_ENABLED=1
5. Consistent user experience in both modes,
6. No need to maintain two sets of code CGO_ENABLED=0
7. ebitengine/purego is in beta, so this uses a everything passes in CI approach (and we hope someone continues to maintain ebitengine/purego in the future)

End users experience

Currently users need to

1. Ensure CGO_ENABLED=1
2. Ensure they have a CGO compiler
3. Ensure they have installed the pact-go shared library
4. Ensure the shared library is in an known place for CGO linking (hard coded in pact-go)

With ebitengine/purego, the user just needs to perform 3, and in step 4, they can point pact-go at wherever the shared library lives with no restrictions. This means it can be in non-standard paths, different versions could easily be managed.

Due to size reduces in the native libraries, we could possibly include the shared libraries in the code base. it would inflate the git history, but would make it very easy for uses to just plug and play with pact-go