[Stream] Model execution affinity for cross-device transfers (#24748)

Fixes #21361.

A `stream.async.transfer` currently carries source and target
affinities, but those describe where its input and result reside, not
necessarily where the transfer executes.

This distinction matters when a value produced on device B is
transferred into a result pinned to device A. The problems this can
cause are described in detail in the issue linked above.

This change adds an optional execution affinity to
`stream.async.transfer`, printed as `on(...)`, alongside the existing
`from(...)` and `to(...)` affinities:

  ```mlir
  %result = stream.async.transfer
      on(#hal.device.affinity<@device_a>)
      %source
      from(#hal.device.affinity<@device_b>)
      -> to(#hal.device.affinity<@device_a>)
      !stream.resource<external>
```

A new PlaceTransferExecutionsPass runs before execution scheduling. It uses affinity analysis to identify transfers whose result has a unique pinned affinity and places those transfers on the pinned device when the default producer-side placement is incompatible.

ScheduleExecutionPass then handles the transfer through its normal affinity partitioning. Transfers are only grouped with their producer when their execution affinities are compatible.

The existing staging-transfer placement rules are preserved as the default when no explicit execution affinity is present. Source and target affinities are no longer modified indirectly when setting an operation's execution affinity.

The full Stream pipeline now produces the desired result for the original multi-device case:

  - The device-B dispatch result is allocated with optimal<A, B> affinity.
  - The final external result remains pinned to device A.
  - The transfer into that result executes on device A.
  
  With this https://github.com/iree-org/iree/pull/21589 can also be closed as this implementation should solve the problem.

---------

Signed-off-by: default <ziereis@roofline.ai>