ca: Support separate Vault providers per DC

Currently the [Connect CA](https://www.consul.io/docs/connect/ca) requires that when the [Vault provider](https://www.consul.io/docs/connect/ca/vault) is used, all Consul DCs must either:
* point at the same Vault cluster
* use [Vault replication](https://www.vaultproject.io/docs/enterprise/replication) to mirror the certificate at `root_pki_path` to all clusters, or
* a user must manually copy the root cert to all clusters

This requirement comes with a number of disadvantages. The manual option is extra work that shouldn't be necessary, and both of the other options require setting separate paths for `intermediate_pki_path` in every DC, otherwise things are pretty broken.

We can allow a separate Vault cluster per Consul DC by changing the two calls to `provider.ActiveRoot` in `SignCertificate` and `initializeSecondaryCA` to use the root CA that is fetched from the primary DC, instead of attempting to retrieve it directly from Vault.

This would not only enable separate Vault instances, but would also allow someone to use different CA providers per datacenter. While that may not be a desirable long term option, it does seem like a pretty important thing to support for doing an incremental switch over from one provider to another, one DC at a time.

**Acceptance Criteria**

1. Write a test showing that a separate Vault instance can be used for the primary and secondary Consul DCs, and that the secondary is able to sign leaf certs. The test should both re-initialize the CAManager at least once, and also separately show an update of the configuration. Currently the calls to `Provider.ActiveRoot` only happen in those scenarios, so we won't notice the problem until those operations are performed.
2. Address the structural problems in the code that make it trivial to re-introduce the problem. Currently `ca.Provider` interface makes no distinction between the methods that are safe for use in the secondary DC. We should split up this interface into `ProviderPrimary` and `ProviderSecondary`. Also, any methods on `CAManager` should either be safe for both primary and secondary, or they should be explicitly named `primaryX` or `secondaryX` to make it clear where they are used. In the future we may be able to split those methods further onto separate types. This work was started in #11340.

Start with SignCertificate and initializeSecondaryCA, focusing on their calls to Provider.ActiveRoot and how the root CA is fetched from the primary datacenter. Review the ca.Provider interface, CAManager methods, and the work started in #11340. Done means tests cover separate primary and secondary Vault instances, secondary leaf signing, CAManager re-initialization, and configuration updates, with primary and secondary provider methods clearly separated.

Written by the indexing model from the issue text.