In preparation for moving to a struct based model where
a `CryptoProvider` has a `&'static dyn SecureRandom` field, this commit
splits the `SecureRandom` trait from the `CryptoProvider` trait. In its
place `CryptoProvider` gets a `secure_random(&self)` fn that acts as
a stand-in for what will be a field in the struct based approach.

We're working towards making `CryptoProvider` a struct holding distinct
elements to be used for cryptography. To support this the
`load_private_key` fn needs to be lifted to a new trait, `KeyProvider`.
We can hold a `&dyn KeyProvider` in the to-be-added struct to invoke
as required for `load_private_key`.

This commit adds the new trait, includes `KeyProvider` in the existing
`CryptoProvider` trait bounds, and updates the *ring*, aws-lc-rs, and
provider example crypto providers to implement `KeyProvider`.

In preparation for moving to a struct based model where
a `CryptoProvider` has a `&'static dyn KeyProvider` field, this commit
splits the `KeyProvider` trait from the `CryptoProvider` trait. In its
place `CryptoProvider` gets a `key_provider(&self)` fn that acts as
a stand-in for what will be a field in the struct based approach.

This commit replaces the existing `CryptoProvider` trait with
a `CryptoProvider` struct. This has several advantages:

* it consolidates all of the cryptography related settings into one API
  surface, the `CryptoProvider` struct members. Previously the provider
  had methods to suggest default ciphersuites, key exchanges etc, but
  the builder API methods could override them in confusing ways.
* it allows removing the `WantsCipherSuites` and `WantsKxGroups` builder
  states - the "safe defaults" are automatically supplied by the choice
  of a crypto provider. Customization is achieved by overriding the
  provider's struct fields. Having fewer builder states makes the API
  easier to understand and document.
* it makes customization easier: the end user can rely on "struct update
  syntax"[0] to only specify fields values for the required
  customization, and defer the rest to an existing `CryptoProvider`.

Achieving this requires a couple of additional changes:

* The cipher suite and key exchange groups are now expressed as `Vec`
  elements. This avoids imposing a `&'static` lifetime that would
  preclude runtime customization (e.g. the tls*-mio examples that
  build the list of ciphersuites at runtime based on command line
  flags).
* As a result of the `Vec` members we can no longer offer the concrete
  `CryptoProvider`s as `static` members of their respective modules.
  Instead we add `pub fn default_provider() -> CryptoProvider` methods
  to the `ring` and `aws-lc-rs` module that construct the `CryptoProvider`
  with the safe defaults, ready for further customization.

[0]: https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax