Reconsider support for secret key storage

We decided to move away from native support for various secret stores. The arguments were:

• When we support X, people will ask for Y. And then for Z.
• We don't want the (big) SDK/client libraries inside the Nuts node for the various secret stores (Azure seemed to be a big, big dependency to include).

However:

• Having to deploy a secret store adapter (e.g. Hashicorp Vault, MS Azure Key Vault, Amazon AWS Key Manager) adds another container to the microservice hell.
• When (enough) people use Y, why shouldn't it be supported out of the box? After all, the tool exists because it brings value (the question of who'll maintain it, is a different question)
• The Azure Golang SDK is now modularized, so including the key vault client doesn't mean pulling the entire Azure SDK inside Nuts.
  • I noticed IRMA now includes the MS SQL Server Golang driver, which in turn includes (amongst others) the Azure Key Vault SDK. So we might already include to SDKs/client libraries transitively, even if we didn't want to.

Suggestion:

• Allow native support for other key storage (than fs and external) again, but only if it's going to be maintained
• If there's no-one maintaining an implementation (meaning there is nobody using it, or at least not willing to put effort into it), it can be removed
• Un-deprecate the vault (Hashicorp) key storage implementation again
• We could keep the external option for customizability, for future use or deprecate it

Start by reviewing the current key-storage options mentioned in the issue: fs, external, and the deprecated vault implementation. Determine which implementations are still present and what maintenance or dependency work would be required to restore native support. Done means reaching a clear decision on supported stores and maintaining or removing the relevant implementations.