Dynamic inclusion of system truststores

## Feature Request

### Crates

tonic

### Motivation

I have a client library using tonic which connects to a server. Depending on deployment configuration, this server may be deployed with a real, publicly issued TLS certificate or a self-signed certificate. In the self-signed instance, the CA is provisioned to disk by deployment infrastructure and it's important that only that CA is trusted.

Tonic presently allows specific CAs to be added by using `ClientTlsConfig::ca_certificate`, and these are registered at an appropriate time. Separately, one can add the `tls-roots` feature, which adds a dependency, and then the system CA roots are added forcibly in each use case.

For this use case, tonic may be used by multiple libraries in the eventual application, so it's undesirable for another application pulling in the crate with the tls-roots feature to change the behaviour of our library. Additionally, it's undesirable for us to need to compile two versions of our application, one with the system roots added, one without.

### Proposal

Either:

Add an enum to ClientTlsConfig named something like

```rust
#[non_exhaustive]
pub enum TlsRoots {
CustomRoots(Certificate),
#[cfg(feature = "tls-roots")]
SystemRoots,
#[cfg(feature = "tls-webpki-roots")]
WebPkiRoots,
}
```

Then, the configuration could contain a HashSet of TlsRoots which could be added to or overwritten via the config, and the system roots only added if the set contains the relevant variants.

Alternatively, one could add methods

```rust
#[cfg(feature = "tls-roots")]
pub fn disable_system_roots(self) -> Self;

#[cfg(feature = "tls-webpki-roots")]
pub fn disable_webpki_roots(self) -> Self;
```

which has the same effect of causing them to not be added. This has the drawback that in order to maintain present behaviour, the flag is a 'disable' type flag and not an enable flag.

### Alternatives

Haven't considered any alternatives.