We were previously just treating promising.ErrUnresolved as a singleton
that doesn't carry any context along with it. This particular error always
represents a bug in the stack runtime rather than a problem with the input,
because resolving all of the promises is a key part of the contract for
package promising, but it's still helpful to know a little more about what
exactly has failed when debugging it.
Therefore promising.ErrUnresolved is now a type rather than a value, and
its carries with it a set of promise ids that were left unresolved. The
stackeval package then recognizes this error type and uses its own records
of what each promise was supposed to produce to hopefully return a useful
error message that would narrow down what part of the system is buggy.
Since this message always reflects a bug in Terraform the error message
will probably just be copy-pasted into a bug report, and so this particular
diagnostic type (unlike the one we use for promise self-references) only
has one presentation form that we use regardless of how many promises
we have to return.
For the main Terraform language runtime we've traditionally used an
explicit directed acyclic graph to manage the order of execution, which
is effective and proven but leads to an unfortunate inversion-of-control
programming style both for graph construction and graph walking that can
be difficult to read and debug.
For the stacks language runtime we're going to use a slightly different
approach of writing some relatively normal-looking functions that each
appear to be normal straight-through code but internally are running
as collaborating goroutines. This should make the control flow and data
flow somewhat clearer.
An important building block for this is a way for these different
functions to asynchronously provide data to one another without the risk
of deadlock. This new package "promising" provides that by modeling a
bipartite graph of tasks and promises, where each promise has a single
task responsible for resolving it and each task has zero or one promises
it's waiting for. If any task attempts a wait that would introduce a
cycle into the graph then the get operation immediately fails to avoid
a deadlock.
