[DispatchCreation] Preserve the target of materialized tensor layouts (#24968)

Once tensor layouts have been materialized for a device, dispatch
creation must neither assign encodings to them again nor compile them
for another device. Assigning encodings again re-encodes data-tiled
convolutions when convolutions are data-tiled, and tile shapes chosen
for one CPU can be unsupported or slow on another.

Record the target in the `iree.encoding.materialized_layout_target`
module attribute. Typed accessors live in
`DispatchCreation/MaterializedLayoutTarget.h`; `Encoding/Utils` cannot
depend on HAL because HAL/IR depends on Stream/IR, which depends on
`Encoding/Utils`. The header lists every behavior the attribute changes.

- `iree-dispatch-creation-assign-data-tiling-encodings` skips such
modules. It is a module pass so that no function pass has to read the
attribute. Its options carry the operation families and encoding
strategy, so printed pipelines and crash reproducers keep them. The
default operation families now come from one helper,
`getDefaultDataTilingOpTypes`.
- `iree-dispatch-creation-verify-materialized-layout-target` runs first
in the dispatch-creation pipeline, independent of the data-tiling
options. It rejects modules compiled for a different target, for several
targets or for none.

Resuming with `--compile-from` reuses the serialized device targets, so
a normal `iree-compile` flow does not retarget. The check guards
hand-edited IR and tools that rewrite device targets. Nothing sets the
attribute until #24969.

This is one of five PRs adding an experimental CPU path that
materializes data-tiling layouts before dispatch creation, so that
`linalg.mmt4d` and data-tiled convolutions fuse with their elementwise
epilogues and result unpacks.

Assisted by AI.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>