[Feature Request] WSL device discovery

### Describe the feature request

At the moment, GPU discovery on Linux worked by iterating over DRM nodes.
This approach won't work on WSL since the DRM kernel side isn't present.
There are different approaches to resolve this

- iterate over PCI devices for WSL instead of DRM devices. PCI devices with dxcore driver are paravirtualized GPUs
- 👍 super-fast
- 👍 mostly matches current Linux logic, could unify with Linux logic
- 👎 can't get much information from paravirtualized sys fs
- 👎 unclear how to get info to match virtual PCI bus ID with real CUDA device for CUDA EP / TRT NV EP
- use dxcore library, dynamically load it when `/dev/dxgi` is present
- 👍 dxcore API gives rich info on devices (vendor, device type, VRAM, etc)
- 👍 works cross-vendor
- 👎 getting adapters seems to take longer than just iterating over sysfs files
- 👎 to match with CUDA device, LUID doesn't work since it is the LUID of the paravirtualized device. One can get the real PCI bus id via KMT2/KMT3 API which allows matching with CUDA devices.
- ioctls on `/dev/dxgi`
- same tradeoffs as with dxcore lib, but we wouldn't need to dynload a library if we only need very few info
- nvml
- 👍 solution much shorter in terms of lines of code than dxgi
- 👍 nvml is available on Linux, in containers, VMs and WSL whenever a Nvidia driver is installed. It gives a strong indication that a Nvidia device is present
- 👍 get real PCI bus id directly
- 👎 `nvmlInit` is slower than iterating sysfs

I have a draft with the nvml solution and parts of dxcore outcommented (I have a working dxcore solution as a standalone project) here https://github.com/microsoft/onnxruntime/pull/27287

@edgchen1 @gedoensmax

### Describe scenario use case

Device discovery in WSL should behave like regular Linux, so WSL could serve as a developer platform for desktop and cloud Linux platforms