This is kinda awkward because this address type represents both resources
whose own instances are not expanded yet and resources belonging to whole
modules whose instance keys haven't been expanded yet, and those two cases
have different address types.
However, in return for this awkward API only for the rare case where we
need to isolate the module instance address, the rest of the system gets
to not worry very much about this distinction: it can share most code
between the two cases, since they both need similar evaluation treatment
anyway.
Currently we have a slightly different treatment for each of the different
kinds of named values, which makes it hard to generalize the
implementations of their very similar behaviors.
This package should over time take ownership of the problem of tracking
all three kinds of named value during a graph walk, with result data
structures that use this information (such as state and plan objects)
copying the relevant values out of here only once the graph walk is
complete.
Nothing is using this yet, though. Some retrofitting of this into
Terraform Core will follow in subsequent commits.
This logic was previously incorrect for any case where the number of
expanded steps was zero, causing the string representation to begin with
a dot when it ought not to.
In preparation for making it not an error to have unknown values in count
or for_each arguments, we will need a way to talk about the
as-yet-undetermined set of module or resource instance addresses that
will result once we _do_ learn the instance keys in a later step.
Unlike many of our address types these have unexported internals so that
we can do some semi-uncool things with our address types that external
callers are not normally supposed to do. This means they therefore need
a bunch more methods than our address types typically need so that it's
possible to access the relevant parts of the internal representation.
