When the removed_provisioners experiment is active, removed blocks
referring to managed resources are allowed to include "connection" and
"provisioner" blocks, as long as all of the "provisioner" blocks specify
when = destroy to indicate that they should execute as part of the
resource's "destroy" action.

This commit only deals with parsing the configuration. The logic to react
to this during the apply phase will follow in later commits.

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.

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, 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.

This records in a test that both `count.index` and `each.key` will
validate properly within a `removed` block provisioner.