Windows MSVC compile fix for SA2, SA3

[loscrossos]

TLDR;

see below.
@jt-zhang the Error is not really on Sageattention but on Pytorch. No sure about best way to proceed. anyways i creted the PR so people wanting to compile on windows can apply it. Or accept it and make people happy. this fix does not affect Linux or other windows compilers apart from MSVC.

Sage2 and Sage3 compile. on windows the mem misalign bug is still there and not fixed by this PR. only compile.

Problem

When building the CUDA extensions on Windows we were seeing a build error from a
PyTorch header:

error C2872: 'std': ambiguous symbol
…compiled_autograd.h(1135)…

The failure wasn’t in any of our CUDA kernels at all, but in the host‑side translation unit generated by nvcc. compiled_autograd.h contains a #if that only keeps the large std::‑heavy else branch out of the build if the
USE_CUDA (or USE_ROCM) macro is defined.

https://github.com/pytorch/pytorch/blob/d33f96c5ccb43430ec2db286ea6490da9035895d/torch/csrc/dynamo/compiled_autograd.h#L1118

Without that macro the else branch is evaluated, the compiler trips over an MSVC namespace/typedef collision,
and the ninja build aborts.

Solution

Ensure that every compilation of our extension passes -DUSE_CUDA to the host compiler. This mirrors the definition PyTorch itself uses and forces the header to take its safe "CUDA-enabled on Windows" path.

The change simply adds -DUSE_CUDA to both CXX_FLAGS and NVCC_FLAGS in setup.py.
This change only affects Windows/MSVC (DISTUTILS_USE_SDK ) and not other windows compilers (MinGW etc).
No behaviour of the library is altered on Linux/other platforms.

Result

Builds now succeed on Windows with recent PyTorch/CUDA combinations; the
previous “ambiguous std” error is gone. The fix is entirely internal to the
build system and does not affect runtime functionality.

[wzgrx]

not work