Add CUDA Plugin EP CI and fix Windows plugin build support

[tianleiwu]

Summary

This PR improves CUDA Plugin EP development and validation in three areas:

Fixes the Windows CUDA Plugin EP build so the plugin can be compiled successfully with MSVC.
Adds dedicated Windows and Linux GitHub Actions workflows for building and testing the CUDA Plugin EP.
Expands the quick start documentation with instructions for running the CUDA Plugin EP Python tests locally.

Changes

Windows build fixes

• Update the CUDA plugin CMake configuration to use the correct forced-include flags on Windows/MSVC.
• Keep the existing forced-include behavior for non-MSVC toolchains.
• Add the missing GetEnvironmentVar(const std::string&) forward declaration needed by plugin builds on Windows.

CI coverage for CUDA Plugin EP

Add a Windows CUDA Plugin EP workflow that:

• builds ONNX Runtime with onnxruntime_BUILD_CUDA_EP_AS_PLUGIN=ON
• uploads build artifacts
• installs the built wheel
• sets ORT_CUDA_PLUGIN_PATH
• runs test_cuda_plugin_ep.py

Add a similar Linux CUDA Plugin EP workflow.

Documentation updates

• Add a Running Tests section to the CUDA Plugin EP quick start.
• Document test prerequisites, dependency installation, and ORT_CUDA_PLUGIN_PATH.
• Clarify that CPU-only PyTorch is sufficient for test_cuda_plugin_ep.py because it is used for CPU-side reference computations.

[github-actions]

You can commit the suggested changes from lintrunner.

[yuslepukhin]

Factory fallback CreateSyncStreamForDeviceImpl (cuda_ep_factory.cc:531-549) does not validate mem_type == OrtDeviceMemoryType_DEFAULT, unlike the CudaEp-level version. This inconsistency is pre-existing but could be confusing.

[yuslepukhin]

SyncImpl restores device even when cudaSetDevice(ep->config_.device_id) fails. If cudaSetDevice fails, cudaDeviceSynchronize is skipped (good), but the restore branch still runs cudaSetDevice(prev_device). This is harmless since the device may not have changed, but the restore status would overwrite the original error if it somehow fails too. The current priority logic (if (status.IsOK()) status = restore_status) handles this correctly — only propagates restore error if the primary op succeeded.

[tianleiwu]

@yuslepukhin, for sync stream related issues, I could address them in another PR. This PR is mainly for CI setup.