terraform console: Option to evaluate in a planned state

[apparentlymart]

Previously terraform console always evaluated in a kinda strange context where resource instance data comes from the prior state, but other derived of values end up being calculated dynamically based on the current configuration, which is okay for simple cases but can be confusing if the configuration has changed significantly since the most recent apply, or if there haven't yet been any applied changes.

Now we'll allow an optional new mode where Terraform runs the normal plan phase (as if running terraform plan) and then uses the resulting planned state as the basis for evaluation, allowing evaluation against a partial approximation of what the world ought to look like if these changes were applied, without having to actually apply them first.

As with the previous use of the eval walk, it's possible that an erroneous situation will still produce a partial evaluation scope, and so the console still allows evaluation against that scope but with a caveat that it might produce unexpected results. In practice this can be useful for debugging situations like when unknown values block planning of an object, to allow inspection of the values that are contributing to that blocked planning operation even though the plan is not yet complete.

---

Working on #34338 yesterday, and realizing that the test language has requirements that are a mix of some requirements from the stacks language and some requirements from terraform console, made me recall an old idea of allowing terraform console to run in the context of a generated plan as a way to have more information available in scope, and as an additional option for debugging situations where unknown values are ending up in unfortunate places.

Since that PR already did most of the work to make this possible, this PR is a little extra value-add from #34338 to fill a little gap we've been hoping to fill for a long while now.

Here's an (admittedly rather contrived) example of using terraform console -plan in a configuration which cannot fully complete planning due to an unknown value in an inconvenient location:

$ terraform console -plan
╷
│ Error: Invalid count argument
│ 
│   on deferred-changes-module-exp.tf line 6, in module "child":
│    6:   count  = length(null_resource.a.id)
│ 
│ The "count" value depends on resource attributes that cannot be determined
│ until apply, so Terraform cannot predict how many instances will be created.
│ To work around this, use the -target argument to first apply only the
│ resources that the count depends on.
╵

╷
│ Warning: Due to the problems above, some expressions may produce unexpected results.
╵

> null_resource.a
{
  "id" = (known after apply)
  "triggers" = tomap(null) /* of string */
}
>  

Although hopefully soon we'll finish working on #30937 and thus the question of where an unknown value originated will become less significant, I think it's still pretty helpful to be able to peek into the details of what values contributed to a plan, such as with the situations I was aiming to improve on in #34312: why is my postcondition failing? why is the provider proposing to replace this object?

[alisdair]

This is delightful! Just a tiny question inline.

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

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