Summary

This PR:

Changes how the plugin-framework implementation of the provider is configured
- Before: Parallel implementation of configuration logic that parses user inputs and populates a fwtransport.FrameworkProviderConfig struct
- After: The configure function obtains an already populated transport_tpg.Config struct from the SDK provider, with no duplication of logic to process user inputs.
Changes code defining the VCR system to accommodate the change above
- Now the PF provider uses the same Config struct as the SDK provider, both providers can use the same cached configs.
- This fixes https://github.com/hashicorp/terraform-provider-google/issues/14158 , because a single test will use a single cached client again.
Makes necessary changes to the data sources currently implemented with the plugin-framework
- These now expect to receive a transport_tpg.Config struct
- Any provider-level values are now in the old type system, and require thought about where we convert between those type systems.

Things to pay attention to during review/testing

What acceptance tests need to be updated now that the PF provider is configured in a SDK-like way?
Are only changes just to the test required, or do the failures indicate user-facing changes in behaviour?
Tests
- 🔴 Acceptance tests for the provider's configuration behaviour are mostly VCR skipped. Testing this PR will require use of TeamCity!
- Manual testing encouraged
- We should look at known bugs linked to the muxing and confirm they're gone before merge
  - https://github.com/hashicorp/terraform-provider-google/issues/16832#issuecomment-2441432304
- After merge, we should closely monitor nightly tests and not rely on the Release Shepherd picking up any failures linked to this PR. Newer tests will provide more signal.

provider: refactored how the provider configuration is handled internally