Enable selecting system certificate stores.

[alilleybrinker]

This commit adds the ability to select what certificate root store to use when making HTTPS connections. Previously, cargo-release was configured to use the default for tame-index, which is the "webpki" root of trust maintained by Mozilla. This is a good and reasonable set of certificates, except for users on networks which substitute certificates.

Substituting certificates is something enterprise networks will frequently do so they can man-in-the-middle HTTPS connections made on their network and thus maintain visibility into the network activities of their employees. In this setup, the users' devices will generally be running enterprise-managed software which replaces certificates used by public websites with ones provided by the network software the enterprise uses, with the root certificates for these substituted chains being placed in the users' local system certificate store. In that case, with only the "webpki" certificate store loaded for cargo-release, the substituted certificates will fail to validate, and publication of new versions (indeed, even checking publication status of the crate attempting to be published) will fail with an HTTPS error about an untrusted certificate.

The solution chosen here was to add a configuration element, and a CLI flag under the "publish" section, which lets the user pick between "webpki" (Mozilla) or "native" (local system) certificate trust stores. The portion of the code in src/ops/index.rs which handles connecting to the registry index has been updated to configure which certificate store to use based on the user's selection.

The one final wrinkle is that we get reqwest, the dependency which actually handles HTTPS connections, through the tame-index crate, which re-exports it. To enable the APIs in reqwest for configuring what TLS certs to pick up, we have to enable the "native-certs" feature on tame-index, while leaving the default features on. This is something tame-index normally recommends against, because it assumes you want to exclusively activate one of them at compile time. In our case, we need the selection to happen at runtime, so we need both to be compiled in.

Fixes #764

[alilleybrinker]

With native certs on, this line caused errors. This line turns off ALPN, so there's no ability to negotiate between HTTP versions. I am not sure why this was causing things to fail, but I kept getting errors with it on. The difference for removing this line is that ALPN is turned on, so HTTP version negotiation can occur.

[alilleybrinker]

Ended up opting to rebase down to one commit, and also fixed the table reformatting so the table is no longer reformatted at all, just has a row added for the new flag. If you'd still like that in its own commit separately, let me know.