Expose cryptography backends via CryptoProvider

[arckoor]

Adds a CryptoProvider struct that allows replacing the built-in providers with something custom.
All the details from this implementation that could be considered "interesting" are stolen straight from rustls's CryptoProvider.

I've marked the new_signer, new_verifier and JWK functions from the two built in backends as pub, so you can do stuff like this:

fn new_signer(algorithm: &Algorithm, key: &EncodingKey) -> Result<Box<dyn JwtSigner>, Error> {
    let jwt_signer = match algorithm {
        Algorithm::EdDSA => Box::new(CustomEdDSASigner::new(key)?) as Box<dyn JwtSigner>,
        _ => jsonwebtoken::crypto::aws_lc::new_signer(algorithm, key)?,
    };

    Ok(jwt_signer)
}

i.e. overwrite just specific algorithms.

One area I'm a little unsure about is JwkUtils, 1) about the name and 2) about the Default implementation. The CryptoProvider::signer_ and CryptoProvider::verifier_factory functions are obviously mandatory for a custom provider, but not everyone uses JWK, so the default just uses dummy functions with unimplemented!().

[arckoor]

@Keats any chance of a review on this?

[drusellers]

Would this allow applications to use rustls rather than openssl?

[arckoor]

@drusellers As far as I know rustls doesn't implement the cryptography directly, rather it relies on other crates like ring, aws-lc-rs, rustcrypto, ...
So you can't really use rustls with this, but you can implement the cryptography with whatever backend you choose, be it openssl, botan, or something else entirely (this crate has aws-lc-rs and rustcrypto built in, using these doesn't require this PR)

[Keats]

I think this can be simplified

[Keats]

that will get more complex if we start supporting some alg in some backend like #461

[arckoor]

@Keats I made the JWK functions private after all. For the PROCESS_DEFAULT_PROVIDER I still think this is the best way to do it, so I left it as is. I also removed the custom-provider feature, because it wasn't really doing anything anymore after making all the things pub / adding getters, so now you users just select neither of the built-in providers.

In regards to the macro, I also left it as is, if #461 goes through and does gate the implementation itself behind a feature, I guess the best would be to remove the macro and write the functions by hand for each built-in provider.

As for the example, I used the botan-rs crate, though I'm not confident you'll like it, it does force devs (and notably CI) to compile botan from source everytime.
That said, I chose it because 1) rust_crypto and aws_ls_rs are already here, and I didn't just want to duplicate the code 2) ring still seems to be unmaintained 3) openssl you have to compile as well and 4) I'm not aware of other solid options.
I feel it might be best to just duplicate the rust_crypto EdDSA implementation for the example, but then I don't know how useful the example is.
A different way to do it would be to introduce an internal __custom_provider_example = [dep:botan] feature, but that doesn't sound too great either :/