[Stream] Implement SpecializeEncodings pass (1/n)

[hanhanW]

There are three major changes in the revision:

• Introduce AffinityAnalysisDialectInterface Stream dialect interface. It is used to fetch attributes that are defined by other dialects. In the revision, HAL implements the dialect interface, and it can return whatever attribute attached in HAL::ExecutableTarget attributes. The main idea of the dialect interface is that Stream does not need to depend on HAL to get the layout information.
• Add cloneWithLayouts method to the EncodingAttr. It is used in the encoding specialization pass where it can resolve the layout requirements and add it to the layouts field. The other optional parameters are dropped because the layout is already resolved. It can be a new Encoding dialect attribute because it is just describing the layout. The stream tensor ops do not need to know the op_type, element_types and operand_index parameters. It only needs the layout information, and the attribute should implement the interface method.
• Partially implement the SpecializeEncodings pass. The responsibility of the pass is large, so I decide to implement it incrementally. This revision only implements the mechanism of updating stream tensor ops' encoding, and only stream.tensor.sizeof op is supported. The rest of the support for other stream tensor op can be added later on. The executable duplication and the update of dispatch ops will be implemented in subsequent PRs.

[benvanik]

always use full names for things wherever possible - it's useful hints to readers as to what the type is and how it is treated - shortening to arbitrary forms makes it impossible to find/replace in codebases and more difficult for non-native speakers (here and anywhere else you've shortened things).

Suggested change

	return [=](IREE::Stream::AffinityAttr aff, Operation *op,
	return [=](IREE::Stream::AffinityAttr affinityAttr, Operation *op,

[hanhanW]

I see, done.

[benvanik]

as mentioned, affinityAttr (here and elsewhere)

[hanhanW]

Done. @benvanik does my comment above make sense? If so, I'm going to remove the (Is the statement correct?).

[benvanik]

At this point in the IR I don't believe there is a concept of default device, so the whole TODO is not required - in a program with multiple functions there may be many routes to a function through the call graph and we can't locally make decisions about the whole program like that.

[hanhanW]

@benvanik can you take a second look at this?