Improve end customer testing of acquiring packages that ship as beta, combined with other packages that are GA.

It is important for customers to be able to adopt our specific beta packages, easily, so they can provide valuable feedback on new features, while keeping the rest of the dependency graph stable.

For example, have a test job (running in CI/nightly) where the customer can successfully build an application using a GA'd version of `azure-core-cpp`, with a beta version of `azure-identity-cpp` (or any other beta client package), acquiring them via vcpkg.

Such end-user package acquisition testing will help catch build issues that require patching the beta registry.
An example of that was here:
https://github.com/Azure/azure-sdk-vcpkg-betas/commit/ad5bdf2169956569826f25f11c6aa9294948e7bc
https://github.com/Azure/azure-sdk-for-cpp/pull/6042

Currently, our CI pipeline tests and verifies all sources in main build well together, and [the CI in the vcpkg main registry](https://github.com/microsoft/vcpkg/pull/34835) tests to ensure all GA'd packages work well. But there's a gap where beta packages are mixed with GA'd packages.

A way to simulate that scenario and repro the issue is by building an application which only contains the specific beta package being tested in its `vcpkg-configuration.json`, and not the entire list of packages we ship (for example, filtering this down to just `azure-identity-cpp` results in vcpkg getting the `azure-core-cpp` dependency from the GA registry):
https://github.com/Azure/azure-sdk-vcpkg-betas/blob/62c56807f81f0cae7c6ee97a3eb4edc79f2c5481/vcpkg-configuration.json#L13-L30

cc @RickWinter, @ronniegeraghty