decoder: Fix collection of implied declared targets of complex types

[radeksimko]

As discovered in #251

UX Impact

There currently aren't any constraints in the Terraform schema involving targetable List/Set/Tuple/Map/Object - most occurrences are either not targetable or are implied through LiteralType or AnyExpression, or part of OneOf where AnyExpression takes precedence when collecting targets.

TL;DR there's no expected UX impact on Terraform LS users.

This was only discovered because some existing tests being updated in #251

Implementation Notes

There are situations where the schema may be vague and the user may benefit from seeing the fully inferred type, rather than just any in certain contexts. We already do that for the most obvious case of LiteralType{Type: cty.DynamicPseudoType} and AnyExpression{} equivalent.

hcl-lang/decoder/expr_literal_type_ref_targets.go

Lines 18 to 23 in d2c7ba3

	if typ == cty.DynamicPseudoType {
	val, diags := lt.expr.Value(&hcl.EvalContext{})
	if !diags.HasErrors() {
	typ = val.Type()
	}
	}

We could potentially implement InferType() for all the impacted types, but there's no immediate benefit given the above + this would require some more changes to take advantage of such type inference. We'd e.g. have to introduce TypeHint to TargetContext and get all the expression types to actually use the inferred type when collecting the targets.

The edge cases this could handle involve either explicit List, Set, Tuple, Map or Object constraints with cty.DynamicPseudoType element type, or LiteralType{Type: cty.List(cty.DynamicPseudoType)} and similar.

[dbanck]

I like the approach and we can always refine it in the future if necessary.