Align for_each collection validation with its documented key semantics

## Summary

`BaseConfig.expandBlock` reports that `for_each` accepts a set or map, but its validation accepts every cty value for which `CanIterateElements()` is true. Lists, tuples, objects, and sets with non-string elements are therefore accepted with semantics that are broader than the diagnostic and Terraform-style `for_each` behavior.

Observed on `main` at commit `1d1c394b55ea36a8dc98495850430e4da643b1eb`.

## Reproduction

All of these currently reach expansion:

```hcl
example "item" {
for_each = ["a", "b"]
}

example "number" {
for_each = toset([1, 2])
}

example "empty" {
for_each = []
}
```

The validation is only:

```go
if !forEachValue.CanIterateElements() {
return nil, fmt.Errorf("invalid `for_each`, except set or map: %s", attr.Range().String())
}
```

https://github.com/Azure/golden/blob/1d1c394b55ea36a8dc98495850430e4da643b1eb/base_config.go#L294-L309

## Actual behavior

Values outside the stated set/map contract are expanded. Sequence indices and arbitrary cty keys become instance keys through `CtyValueToString`, making address stability depend on undocumented behavior.

## Expected behavior

The accepted type family and key semantics should be explicit and consistent across validation, diagnostics, addresses, and tests.

For Terraform-compatible behavior, accept maps/objects and sets of strings, and reject lists, tuples, and non-string sets. If Golden intentionally supports all iterable values, update the error and document stable key/address semantics for each supported family.

## Suggested direction

Centralize `for_each` type validation before iteration and add table-driven tests for map, object, `set(string)`, list, tuple, empty collections, and non-string sets.

Start with `BaseConfig.expandBlock` in `base_config.go` at the linked lines and trace how `for_each` values are validated and converted to instance keys. The issue leaves open whether to enforce Terraform-compatible types or document broader iterable support, so settle that contract before changing validation. Add table-driven tests for the listed collection types; done means validation, diagnostics, addresses, and tests agree with the chosen semantics.

Written by the indexing model from the issue text.