Return diagnostics instead of panicking for null or unknown for_each values

## Summary

`BaseConfig.expandBlock` checks only `cty.Value.CanIterateElements()` before calling `ElementIterator()`. Typed null and unknown collection values can report that their type is iterable while still being impossible to iterate, so untrusted HCL input can panic the host process during `for_each` expansion.

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

## Reproduction

Use a registered block with a `for_each` expression backed by an input variable:

```hcl
variable "items" {
type = map(string)
}

example "item" {
for_each = var.items
}
```

Then assign either of these cty values to `items` before `InitConfig`/planning:

```go
cty.UnknownVal(cty.Map(cty.String))
cty.NullVal(cty.Map(cty.String))
```

## Actual behavior

The value passes `CanIterateElements()`, then `ElementIterator()` panics because the collection is unknown or null:

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

## Expected behavior

Expansion should return a source-ranged diagnostic explaining that `for_each` must be non-null and wholly known before expansion. It must not panic.

## Suggested direction

Before creating the iterator, reject null values and values that are not wholly known. Add regression tests for typed unknown maps/sets, typed null maps/sets, and nested unknown elements where keys cannot be established safely.

Start in base_config.go at BaseConfig.expandBlock, especially the for_each expansion around the linked lines, and reproduce the issue during InitConfig or planning with typed unknown and null cty values. Add regression coverage for unknown and null maps or sets and nested unknown elements; done means expansion returns a source-ranged diagnostic requiring a non-null, wholly known value instead of panicking.

Written by the indexing model from the issue text.