Make the workspace command explicitly protect the default workspace, instead of relying on backend implementations

[SarahFrench]

This PR makes the terraform workspace delete command return early with an error if the user attempts to delete the default workspace.

Currently this protection already exists but it's re-implemented within each backend in the repo, for example:

• s3 protects default
• azure protects default
  
• gcs protects it too
• so do other backends like pg and kubernetes.

Assuming that the only code that deletes a workspace is within the terraform workspace delete command's logic, we can move this protection into the command itself.

This makes the protection of default an explicit responsibility/feature/choice of Terraform core and not just a convention of the existing backend implementations in this repo.

Target Release

v1.13

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[radeksimko]

LGTM. Good observation about this behaviour.

I wonder if we should also document this somewhere, e.g. https://developer.hashicorp.com/terraform/cli/commands/workspace/delete and clarify what we expect the user to do (probably delete the files manually) in situations that they actually want to delete it and the consequences of doing so. This could be a separate PR though - I wouldn't want to block this one on docs.

[SarahFrench]

That's a good idea- however I'll wait before merging this PR as I need to figure out the correct way to time updating the docs in the new repo relative to when the new minor's first beta is released.