`iter_mode` / `make_iter_mode` issues and potential cleanup

[danhoeflinger]

Current Behavior

make_iter_mode calls scattered throughout algorithm implementations force compile-time resolution between user-embedded access modes (in sycl_iterator) and algorithm-required modes via iter_mode_resolver. Conflicting modes without a matching specialization trigger a static_assert.

Issues

1. Resolution logic is scattered: Access mode resolution happens via make_iter_mode calls throughout algorithm implementations rather than centrally in __get_sycl_range when the sycl_iterator is actually processed.

2. Incomplete recursion through fancy iterators: iter_mode only recurses through zip_iterator. It does not recurse through:

   • permutation_iterator
   • transform_iterator
   • reverse_iterator

   If a user wraps a sycl_iterator in any of these, make_iter_mode passes it through unchanged via the generic "common iterator" overload, never reaching the underlying sycl_iterator for resolution.

Proposed Improvement

Move access mode resolution into __get_sycl_range at the leaf level when processing sycl_iterator (or types where is_hetero_iterator_v is true). This would:

1. Centralize resolution logic in one place, so it always occurs
2. Automatically handle all fancy iterator compositions since __get_sycl_range already recurses through them
3. Allow removal of most/all make_iter_mode calls from algorithm implementations
4. Ensure consistent behavior regardless of iterator wrapping

[timmiesmith]

@danhoeflinger does #2617 address this?

[danhoeflinger]

@timmiesmith Thanks for pointing me to this because it reveals an issue with #2617 I think. It is toward the same end, but is missing something to resolve (2).
It takes a different strategy in that we basically eliminate the notion of a resolution of iter_mode resolver for all cases other than for_each. This resolves the messiness from (1). The idea behind this is that the "hints" provided by a user are really only useful with a parallel operation like for_each where we may need fewer permissions than read_write based upon what function is to be applied to each element. It would allow us to potentially skip copies in or out based upon user hints.

However, (2) is not resolved by the new machinery for extracting the iter mode, and needs to be addressed by adding some recursive layers to handle our custom iterator wrappers, and perhaps reverse_iterator. Right now that PR only handles the case where sycl_iterators are passed into the API without custom iterator wrappers.