In the stacks model a component is essentially a container for a tree of
normal Terraform modules, and so anything that can appear in a Terraform
module can in principle appear inside a component.
With that in mind here we define a generic type that can represent
anything from package addrs belonging either to a stack configuration
(before instance expansion) or to a stack instance (after instance
expansion), and some aliases for a few combinations that make sense
together, such as stackaddrs.AbsResourceInstance being an
addrs.AbsResourceInstance belonging to a stackaddrs.AbsComponentInstance.
We'll probably add more aliases here later, but this is a starting set
that I expect will arise while implementing the planning-related models
for stacks.
If a stack configuration has a dependency cycle we'll tend to detect it
by the promises failing to resolve due to a self-reference. Describing
that situation to end-users has been historically hard in existing
Terraform's dag-based implementation, and there are some similar
challenges for this promise-based design too.
To deal with it while minimizing runtime overhead in the happy path we'll
teach the various objects to retroactively report names for the promises
they've already instantiated and then only when we encounter the
ErrSelfDependent error will we walk the tree of objects to find
user-friendly names for all of the promises that have contributed to the
results so far.