chore(KMS): cleanup isolated and redundant KMS resources

[eeaton]

Address #1248:

• remove standalone CMEK configuration applied only to cai_monitoring module (tech debt from copying this module from somewhere else)
• remove prj-$env-$bu-kms projects which are contradictory to best practice guidance on how to manage KMS host keys. Use the pre-existing prj-$env-kms projects instead.

[daniel-cit]

Maybe regarding CMEK in 0-bootstrapit cloud be made optional since the common KMS project does not exist yet and the user may need to enable CMEK on the Terraform state bucket

[eeaton]

You're right Daniel, I was working through some incremental changes and seeing the CI results, it has produced this error when tearing down the bootstrap stage:

Step #34 - "destroy-bootstrap": Resource module.seed_bootstrap.module.kms[0].google_kms_crypto_key.key[0] has
Step #34 - "destroy-bootstrap": lifecycle.prevent_destroy set, but the plan calls for this resource to be
Step #34 - "destroy-bootstrap": destroyed. To avoid this error and continue with the plan, either disable
Step #34 - "destroy-bootstrap": lifecycle.prevent_destroy or reduce the scope of the plan using the -target
Step #34 - "destroy-bootstrap": option.}
Step #34 - "destroy-bootstrap": Test: TestBootstrap

I'll revise this.

And regarding "Maybe regarding CMEK in 0-bootstrapit cloud be made optional since the common KMS project does not exist yet and the user may need to enable CMEK on the Terraform state bucket"...
Right, it was my intent to not modify the CMEK on the bootstrap state bucket yet, but I made a mistake on the last commit. I'll be recommending we convert to KMS Autokey as soon as it's GA, this will simplify the code and operation significantly from the current state. However, we'll need more design work to plan how to implement that at the bootstrap stage.

[eeaton]

All checks are green... @daniel-cit and @apeabody , can I get approval please?

[daniel-cit]

LGTM

[sleighton2022]

LGTM