feat: Add support for custom signing algorithms

[AntonioAlarcon32]

Some use cases need signing algorithms that aren't available in the library. This change makes the library more flexible by letting users add their own algorithms for signing and verification.

This PR adds support for custom signing algorithms beyond the ones currently implemented in the library. The changes are split into three commits:

1. Library modifications to support custom algorithms.
2. New tests for coverage of new code.
3. Documentation updates for implementing custom algorithms.

The changes modify the existing algorithms Record to support customization, adding some functions to add the signing algorithm. No new dependencies are required

If needed, we have created a working example using EIP-712 (Typed structured data hashing and signing) here:
https://github.com/AntonioAlarcon32/did-jwt-eth-typed-data-signature. Using EIP-712 allows signing of JWTs using wallets like Metamask without any DID document modification, which more coveniently couples DID management with Ethereum accounts.

[mirceanis]

Thank you for the contribution!

There are some open discussions about customizing the verifiers. See #234 #170

Adding signers is no longer necessary as you can specify the signer when creating the JWT.

For adding verifiers, we shouldn't modify the internal mapping globally. Either provide custom verifiers as parameters to verifyJWS / JWT, or adopt a builder pattern to construct a verifier that supports extra algorithms.

[juanelas]

Thank you for the prompt reply. I'm working with @AntonioAlarcon32 in the same project.

You point us to the actual support of external signers. However, they are not an option since they can be only used for the algorithms that are already hardcoded internally, and we need to use different ones, such as EIP-712.

On your Jul 5 2022 comment to issue #170 you considered removing the internally hardcoded mapping of algorithms to signers and verifiers. This would be in our option a good approach. One way to address it would be to create a standard interface/class JWTSigner supporting one or more algorithms that are able to sign with, and something similar with verifiers. In order to keep backwards compatibility (no breaking changes), we think we could support both the actual Signer signature and the new JWTSigner.

Would you consider such an approach for merging? If it is case, we could start developing it promptly.

Thank you in advance for your time!