[Feature Request] CPU EP `Where` data type registration, add int8 and uint32

Describe the feature request

The CPU EP Where op awkwardly supports unsigned uint8 and signed int32, but not signed int8 and unsigned uint32. Since the logic is already there for uint8, adding int8 adds no code bloat (because it's simply a reinterpret_cast or BitCast away), and similar for uint32. So there is no binary size tradeoff to consider here.

^{https://github.com/microsoft/onnxruntime/blob/main/docs/OperatorKernels.md#operators-implemented-by-cpuexecutionprovider}

More broadly, this is actually true of all pure data movement operators (Gather, GatherElements, GatherND, ScatterElements, ScatterND, OneHot, Where, Tile, Expand...), that ORT should just register sibling data types of the same bitsize if a data type of that bitsize is already registered (so an op with uint8 registered implies int8 and bool8 are also supported, uint32 implies int32 and float32, uint64 implies int64 and float64...). Note at least one other EP (DML EP) already follows this rule data movement operators, that any data type of a given bitsize implies the others are registered too, and we want the CPU EP (as the ultimate fallback EP for ORT) to be at least as complete in coverage for these ops as the smaller EPs.

Describe scenario use case

Implementing the WebNN API in Chromium with OnnxRuntime.dll as a backend.

• https://issues.chromium.org/issues/429859156?pli=1
• https://chromium-review.googlesource.com/c/chromium/src/+/6702792

Start with the CPU Execution Provider section for Where in docs/OperatorKernels.md and compare the registered data types with the issue's table. Review the linked WebNN and Chromium context to clarify whether the work is limited to Where or the broader set of data-movement operators; done means the agreed CPU EP coverage is documented and supported by the relevant validation.