Add support for binary serialization/deserialization for HttpRecorder

[cthrash]

The HttpRecorder did not correctly play back binary content. The propsed fix is to introduce
new fields in RecordEntry named IsRequestBodyBinary/IsResponseBodyBinary, and use base64
encoding/decoding when the payload is deemed to be binary. Currently the test for binary-ness
is a simple MIME type regex match.

Note that this PR includes tests to confirm the new behavior. It will failed to build without
hacking around the fact that the test code depends on the NuGet-installed Microsoft.Azure.Test.HttpRecorder.dll.
If it is preferable to split the PR so you can update NuGet first without the tests failing, please
let me know.

This fix is required for some upcoming additions to CognitiveService/ComputerVision tests.

Description

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• Please add REST spec PR link to the SDK PR
• I have read the contribution guidelines.
• The pull request does not introduce breaking changes.

General Guidelines

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

SDK Generation Guidelines

• If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
• The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code.
• The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

[shahabhijeet]

@cthrash thank you for your contribution.
How soon do you need this change.
Apart from just getting this PR merged with CI passed, we would be taking this change and testing it against the entire repo.
We are still working on updating our CI/CD pipeline so that changes like these can be tested easily via a PR, but we are not their yet.
Here are the steps you will need to roll out this change:

1. Get a private signed binary for HttpRecorder
2. Update the entire repo to start using the new recorder (this will also include your newly written tests)
3. Have the private signed copy part of a private feed that can be used during CI
4. Once the PR is successfully, we can merge that PR.
5. Release the new version of HttpRecorder to nuget.
   OR
   We can do this in our next sprint (as we have started planning for it)
   What is your timeline when you need this change available for your scenarios.

[cthrash]

If you can take over the process, that'd be easiest for me. For now I will disable to the test that breaks with the existing HttpRecorder.
You mentioned a sprint - roughly how soon can I expect a fix?

[shahabhijeet]

@cthrash if this is something that blocks you, we can have this in our next sprint that starts next week.
So let me know how critical is this for your scenario.

[cthrash]

It doesn't block me. Is there an existing issue so I can track?

[shahabhijeet]

@cthrash added an issue to track it

[shahabhijeet]

@cthrash closing this PR as this task is being tracked with an issue linked above.