Invalid terraform when assume_role is set

[spar-eag]

Describe the Bug

When assume_role is set, the generated backend configuration is not valid. E.g.

module "terraform_state_backend" {
  source = "cloudposse/tfstate-backend/aws"
  version     = "1.4.1"
  namespace  = "test"
  name       = "tf-state"

  terraform_backend_config_file_path = "."
  terraform_backend_config_file_name = "backend.tf"
  role_arn = "<my role>"
}

results in the following configuration

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    region  = "eu-central-1"
    bucket  = "test-tf-state"
    key     = "terraform.tfstate"
    profile = ""
    encrypt = "true"

    assume_role {
      role_arn = "<my role>"
    }

    dynamodb_table = "test-tf-state-lock"
  }
}

Applying this result in

Unsupported block type
│ 
│   on backend.tf line 11, in terraform:
│   11:     assume_role {
│ 
│ Blocks of type "assume_role" are not expected here. Did you mean to define argument "assume_role"? If so, use the equals
│ sign to assign it a value.

The generated code should actually be

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    [...]
    assume_role = {
      role_arn = "<my role>"
    }
    [...]
}

i.e. an equal sign is missing. See https://developer.hashicorp.com/terraform/language/settings/backends/s3#assume-role-configuration.

Expected Behavior

I expect correct backend code to be generated.

Steps to Reproduce

See code example above.

Screenshots

No response

Environment

No response

Additional Context

No response

[Nuru]

I have been wanting to get rid of the generated configuration for a long time, as it is difficult to use and difficult to maintain. This was broken in #151 6 months ago, and if even the PR submitter didn't realize it was broken, then, to me, that is evidence that few people are using it and we can safely get rid of it.

@osterman What do you think?