Basic support for provisioners in "removed" blocks

[apparentlymart]

During the apply phase, we'll check if there are provisioners either in the matching resource block or the matching removed block -- whichever of the two is present -- and execute the destroy-time subset of them either way.

This also establishes a standard way to attach a removed block to a NodeResourceAbstract when one is defined, which is likely to be useful for supporting other resource-related meta arguments in removed blocks in future.

removed {
  from = aws_instance.example

  provisioner "local-exec" {
    # All provisioners must have when = destroy in this context,
    # because "removed" resources can only be destroyed.
    when = destroy

    # ...
  }
}

This code is currently accessible only to modules that opt in to the removed_provisioners language experiment, and therefore only available in alpha releases.

---

One known limitation and design question from this initial implementation is:

How should each.key, each.value, and count.index behave when used as part of a provisioner configuration in a removed block?

This is a tricky question because whereas a resource block allows us to determine from the configuration whether we're using count, for_each, or neither -- and treat invalid references as an error -- removed blocks must accept whatever happens to be in the state and so in unusual cases there might even be a mixture of numeric instance keys and string instance keys for the same resource, making it impossible to write a provisioner configuration that would work with both.

---

Other notes/questions for future work:

• Should it be invalid to combine a destroy-time provisioner with destroy = false? Or should that instead mean "run the provisioner just before forgetting the object"?
• Can we and should we provide a new command like terraform rm aws_instance.example that would automatically replace the resource "aws_instance" "example" block with a matching removed block, and copy over its destroy-time provisioners, to avoid the need to migrate them over manually?

---

This is motivated by #34711 and part of #13549 .

[apparentlymart]

Others on the team are considering implementing something like what I prototyped here, so I'm going to close this draft with the hope that it'll be replaced with a more mergeable equivalent soon. 😀

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.