Add customer-managed encryption key (KMS) support to GCS backend

[SarahFrench]

Description

Closes https://github.com/hashicorp/terraform/issues/24967

Currently the gcs backend allows users the option of supplying an encryption key from the client side, customer-supplied encryption keys, which is used as an additional layer of encryption in addition to Google-managed encryption keys. If a key isn't supplied in this way then Google-managed encryption keys are used in the GCS bucket by default.

This PR adds the alternative option of using a customer-managed KMS key to encrypt the state files in the bucket (in addition to Google's own encryption). Details of the KMS key are included in Storage API calls, and retrieving the key is internal to the GCS service.

This encryption method conflicts with the customer-supplied encryption feature that already exists in the backend. There doesn't seem to be a risk of losing state when switching between the two types of encryption. When I've manually tested swaps, in either direction, the write operation results in errors returned from the API and state being OK and accessible in the 'old' encryption style still.

Caveats for users

To use this new encryption method users will need to...

Users not previously using any encryption on their state:

• Create a KMS key chain and key
• Give the GCS service agent permission to use that key by creating a binding with the roles/cloudkms.cryptoKeyEncrypterDecrypter predefined role
• Provide the key's name in the gcs backend configuration
• Perform terraform init and migrate any existing state

Users previously using customer-supplied encryption keys on their state:

• Need to (manually?) create a copy of their state that is not encrypted using the customer-supplied encryption key
  • TODO : Manual process only? Does the backend need to handle this for users?
• Follow the above steps