[Stream] Always map aliases to resolved resource ranges of the source op (#25026)

This ensures that all operands in the tied operand chain for a resource
will get mapped to the correct buffer range.

Previously, if the resource's buffer received a new allocation,
`stream.resource.subview` aliases (by nature of a byte subview, tied to
a different memory range) would still receive resource ranges relatively
to the old resource.
Additionally, all aliases of a given source would be processed from the
"nearest" subview in the alias chain. With multiple subviews in the same
tied operand chain, the offsets weren't computed relative to one
another.

Addressing the first problem enables the most practical use case.
SplitParameterEncoding in "consolidate" mode may need to place an
unmodified input weight into the output buffers, which means the weight
may end up in a packed allocation together with a pre-initialized output
parameter. To later fetch that input weight for dynamic initialization,
an explicit `subview` op is generated (*). Hoisting the constant out of
the execution scope establishes the new resource range, and the subview
should compute its resource range against that. Instead, the old
subrange would get used that was relative to the original SSA source
bound for deletion.
See `Stream/Transforms/test/schedule_allocation_subviews_constant.mlir`
for illustration.

(*) Whether that should be happening is a different matter. Accessing
the packed weight through `stream.async.slice` would've been preferable,
as per a [TODO in
SplitParameterEncoder](https://github.com/iree-org/iree/blob/0df50f9a8e40ab1878479124b952f45d9f8c0650/compiler/src/iree/compiler/Dialect/Stream/Transforms/SplitParameterEncoder.cpp#L1971).
Generally, we should let ScheduleAllocation operate on that abstraction
where a copy will implicitly be generated on writing to the range,
rather than have it account for explicit aliases in that of
`resource.subview`. For now I've preferred not to go into that
direction, because that switch requires larger-scale testing, and
currently explicit subview ops are expected to be supported in the input
IR to the allocator.

By implementing alias mapping as a DFS worklist and simply ignoring
values that have already been resolved to a resource range, nested
subviews, a.k.a. subview ops that reference each other, now correctly
calculate their offset by adding up their own offset to the earlier
offsets in the tied operand chain. Not sure if that does/would come up
in a real case, but at least that's a sensible side effect.

Assisted-by: Codex

---------

Signed-off-by: Artem Gindinson <gindinson@roofline.ai>