guard bundled tbb against gcc cpuid.h / mingw intrin.h conflict

[kevinushey]

Problem

GCC's <cpuid.h> defines a function-like __cpuid macro. If a downstream package includes <cpuid.h> before any TBB header on Windows (mingw), the macro mangles the __cpuid() declarations in mingw's <intrin.h>, which oneTBB's detail/_machine.h includes, and compilation fails:

psdk_inc/intrin-impl.h:2013:42: error: macro "__cpuid" requires 5 arguments, but only 2 given
psdk_inc/intrin-impl.h:2013:6: error: variable or field '__cpuid' declared void

Observed in the wild with the robscale package on r-universe: https://github.com/r-universe/cran/actions/runs/30028399599/job/89335144753

Fix

Suppress the macro via push_macro / pop_macro while including <intrin.h> in the bundled oneapi/tbb/detail/_machine.h. Since mingw's intrin.h is include-guarded, its one-time processing typically happens inside this header, where we control the macro environment -- so this protects downstream packages regardless of their include order. pop_macro restores GCC's macro for any later use in the translation unit.

The guard is a no-op except in the exact broken configuration (mingw + __cpuid macro active). The change is recorded in patches/mingw_cpuid.diff so it can be reapplied when the bundled oneTBB is updated (tools/tbb/update-tbb.R replaces src/tbb wholesale).

Notes

• This diverges from upstream oneTBB; worth proposing upstream as well, since it affects any mingw consumer of TBB.
• Builds against a system TBB use unpatched system headers, but CRAN/Rtools and r-universe Windows builds use the bundled copy.
• Parked here until the dust settles around the 6.0.1 submission; can land in 6.0.2 or a 6.0.1 resubmission as needed.