refactor: deprecate onnx.env.webgpu.powerPreference

[Hengry]

Onnxruntime-web deprecated powerPreference in WebGPUFlag.

Instead, they suggested

Create your own GPUAdapter, use it to create a GPUDevice instance and set device property if you want to use a specific power preference.

Reference:
https://onnxruntime.ai/docs/api/js/interfaces/Env.WebGpuFlags.html#powerPreference:~:text=Create%20your%20own%20GPUAdapter%2C%20use%20it%20to%20create%20a%20GPUDevice%20instance%20and%20set%20device%20property%20if%20you%20want%20to%20use%20a%20specific%20power%20preference.

[fs-eire]

Creating a custom device is supported in onnxruntime-web, but there are also several things to be careful with:

• onnxruntime-web calls adapter.requestDevice(params) with specific requiredFeatures and requiredLimits in params. Creating the device using different params will not be guaranteed to work.
• there are slightly different behavior between different versions for the implementation of dealing with env.webgpu.device and env.webgpu.adapter. the stable implementation is planned for onnxruntime-web 1.22.0 release.

And regarding the "powerPreference" option, it actually makes little difference:

• This option is currently not working in Chrome on Windows: https://issues.chromium.org/issues/369219127

• From MDN:

  Note: On Chrome running on dual-GPU macOS devices, if requestAdapter() is called without a powerPreference option, the high-performance discrete GPU is returned when the user's device is on AC power. Otherwise, the low-power integrated GPU is returned.

  So, the difference between default and high-performance only happens on Macbook with Intel CPU when it's on battery. (seems that is the only macOS device that both has multiple GPU and can run on battery - please correct me if I was wrong)

I am also trying to figure out if setting powerPreference to "low-power" is possibly a real requirement for onnxruntime-web. If not, probably the easiest way is to always set it to "high-performance" in onnxruntime-web.

[xenova]

This can be linked to #960, which we can now work on thanks to onnxruntime-web exposing the device (as you point out in this PR).