Adding support for ETCD encryption with KMS

[Gordonby]

PR Summary

Closes #303

TODO

• Get working for public kv scenario
• Add UI for KMS
• Remove debug outputs from bicep
• Delete KVPolicybased.bicep
  - [ ] Create KMS Sample document that explains the bicep, that we can reference from the Azure Docs (Lets pick up in a different PR thats more docs focussed)
• Make sure it's not using the preview banner.
• Show a warning message if privatelinks is enabled
• Add an information message directing people to CSI KeyVault as a good alternative solution
• Add byo capability
• Test UI combinatons, evaulate if new messages needed
• Test bicep byo kms

UI

PR Checklist

• PR has a meaningful title
• Summarized changes
• This PR is ready to merge and is not Work in Progress
• Link to a filed issue
• Screenshot of UI changes (if PR includes UI changes)

[github-actions]

PR smells stale, no activity for 30 days. Stale Label will be removed if the PR is updated, otherwise closed in a month.

[Gordonby]

@khowling - Thinking of de-scoping the private link scenario here.
Reason being we need to create a private linked keyvault and then somehow get a key created, which becomes instantly harder because we've made it private and the deployment fails.

We could leverage a pattern of creating it public, and inserting the key then updating to be private, but this would be opaque and quite frankly a bit janky.

Options

1. Only support creating a public KV, don't mention private
2. Perhaps we support public with AKS-C, but have a nice message about the private scenario and link to the docs.
3. Look to support BYO KV and Key for private-link scenarios, but there's a pretty significant RBAC burden here. For an existing KV, is it likely the deploying user will have Owner RBAC on the KV in order to give AKS access? Feels like if you need this, you need to properly understand KMS by rolling it yourself.

Thoughts?

[Gordonby]

@khowling - it's ready!

[khowling]

its a good'n