[runtime] Restore "any processor" fallback for unspecified Windows … (#24154)

…read affinity

PR #21089 removed the early-return guard from
iree_thread_request_affinity
but the Windows implementation did not get an equivalent fallback path
for
the "unspecified" case. With group_any=0 and id_assigned=0 the else
branch
built an affinity_mask of `1ull << 0 = 1` and SetThreadGroupAffinity
pinned
the thread to CPU 0; SetThreadIdealProcessorEx then biased the scheduler
  toward CPU 0 as well.

This is the state that threads coming from iree_thread_affinity_set_any
land in — most notably the task executor's poller thread
(executor.c:158).
On a model with heavy poller/worker wake coordination, the poller and
the
worker pinned to CPU 0 ended up contending for the same core, producing
a
~2.5x real_time regression on Windows (cpu_time was unchanged or
slightly
better, consistent with serialization rather than more work). Linux was
unaffected because iree_thread_make_cpu_set_from_affinity already falls
  back to "all CPUs" when neither group_any nor id_assigned is set.

  Mirror that behavior on Windows:
- SetThreadGroupAffinity: when id is not assigned, set Mask=UINTPTR_MAX
so the scheduler is free to place the thread on any processor in the
group.
- SetThreadIdealProcessorEx: skip entirely when id is not assigned
instead of passing Number=0.

  Tested on a 4 thread Windows benchmark: real_time returns from ~102 ms
  back to ~40 ms at this commit, matching the pre-#21089 baseline.

Signed-off-by: Andrew Woloszyn <andrew.woloszyn@gmail.com>