Make Request properties and VCRHandler type public

[Greybird]

Description

The Request object has all its properties set to internal visibility.
However, it is exposed in the IInteractionConverter type under the assumption that an implementation living outside of EasyVCR would be able to return a fully hydrated instance.
More importantly, this defeats the purpose of the MatchRules.ByCustomRule method, which provides Request objects for recorded and received parameters, where the implementor can access absolutely nothing (except though reflection of course).
The test cases do not catch this due to InternalsVisibleTo being applied to the test assembly.

Also make the VCRHandler type public, as there is a specific test stating that its construction should be possible by a user of the library (ClientTest.TestVCRHandler).
It is especially needed to test code using https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-8.0, and dependency injection, especially to be able to inject the handler as indicated in https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-8.0#outgoing-request-middleware.

Testing

I did not write any test.
If this was deemed necessary, then probably test assemblies should be split in two, one for testing the public usage of the library, another relying on internals ? Or an intermediary test utils assembly which would expose publicly methods to act on the internals for tests could be created, to ensure access to internals is under control in tests ?

Pull Request Type

Please select the option(s) that are relevant to this PR.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement (fixing a typo, updating readme, renaming a variable name, etc)

[nwithan8]

Thank you for catching this @Greybird .

If this was deemed necessary, then probably test assemblies should be split in two, one for testing the public usage of the library, another relying on internals?

Yes, in our other repositories, we've begun to adopt two different tests suites, one for unit testing functionality, and another for testing the publicly-available implementation of the module. We should definitely port that to EasyVCR.