Azure KeyVault Implementation Max Secret Size of 25600 causes upsert to fail.

[Waiver-Wire-Addict]

Current Behavior

As identified in #405, the maximum depth for config sets for an Azure Key Vault Store is 1.
If I have a config set based on my environment, let's call it "dev", whenever I add a config to that config set, the Azure Key Vault store stores all the configs in 1 secret called 'dev'.
After about 40 or so configs, some of which are large -- we have had a config upsert fail due to the single 'dev' secret now being larger that the maximum secret size supported by Azure Key Vault.

Expected Behavior

I expected the implementation to handle the maximum secret size and split a config set into multiple secrets to ensure that the secret size limit does not impede the upserting of configs. The Azure Key Vault Secret size is really just a storage chunk size, and I expected the implementation to avoid exposing this limit in this way. Possibly it might make sense to have a maximums size of a config not exceed this limit, but again this limit is sort of small, so I think the implementation needs to be able to split what it stores into multiple secrets and reconstitute configs on the client from multiple Azure Key Vault Secrets.
Or I expected that the config name would be encoded into the secret name, so that by default configu would not store all configs in 1 secret. I expected the code to somehow compensate for secret sizes.

To Reproduce

Create a config with a string with 25601 characters
Try to upsert it into an Azure Key Vault store
You should get the following:
RestError: Secret is beyond the maximum permitted length of 25600 characters.
Code: BadParameter

Context

This issue, coupled with issue 405 -- makes it so that the Azure Key Vault store really only works without config sets -- if you create unique names for all your configs, and don't try to use a config set hierarchy. But if I was doing that, I can just use the Azure CLI to store directly into Azure Key Vault -- and the value that configu brings in organizing configs into hierarchies is lost. When I found configu, I was excited by it -- I could clearly see the value it's architecture provides. I am not in a position to procure the cloud version of configu, and I believe that most of the configu stores based on the Key-Value Store base class will suffer from similar issues that I have identified. If there are other stores that work differently -- if one could be recommended I would appreciate it.