os: add support for windows

[AmyJeanes]

SCons' default tool picks MSVC on Windows; the firmware build and the libpanda test library use the mingw tool with clang there (MSYS2 CLANG64), like openpilot's own Windows build. SCons requires the .dll suffix, so the target and the cffi path are named per platform, and no import library is produced since nothing links against it. The libpanda build inherits the shell's environment so that cmd.exe finds clang on the MSYS2 PATH.

CANPacket_t is memcpy'd onto the USB wire, so the DLL is compiled with -mno-ms-bitfields: mingw's default MS layout would put the checksum at byte 8 instead of 5. cffi's Windows backend follows MSVC bitfield rules and cannot be switched, but MSVC packs same-typed bitfields contiguously, so declaring the three flag bits as unsigned int like addr gives the firmware layout under both rule sets; the layout on Linux and macOS is unchanged.

The signing step runs sign.py through the interpreter running SCons, with SETLEN in the command's environment: cmd.exe, the shell SCons uses on Windows, runs neither a script by its shebang nor a VAR=value prefix. It is the same command on Linux and macOS, spelled out.

Same packet-layout fix as opendbc's libsafety.

panda's own ./test.sh runs on Windows in CI too, which the rest of the change covers:

• The dev dependencies take the ARM toolchain and cppcheck from PyPI (comma-deps-gcc-arm-none-eabi, comma-deps-cppcheck), like the other comma-deps consumers: the release-* shim branches know only Linux and macOS. Those wheels need Python 3.12, hence the markers; bumping panda's Python floor instead would be the other option.
• setup.sh activates the venv from Scripts/ in an MSYS2 shell and pins uv to a native CPython there (the toolchain's own python comes first on PATH, and its wheels are incompatible).
• test_misra.sh calls the venv's python instead of python3: setup.sh has activated the venv by then, and a uv venv on Windows has no python3. The mutation test runs the script through the bash found on PATH rather than the platform shell: cmd.exe cannot run it, and a bare bash would reach the WSL launcher in System32 first.
• test.yaml: a windows-latest entry in the ./test.sh matrix, run from the MSYS2 CLANG64 shell that setup-msys2 provides (only clang is installed on top of the runner's MSYS2; the firmware toolchain comes from uv). Only that entry names its shell; the others keep bash -e {0}, GitHub's implicit default. The existing Windows pip package job stays: it checks the toolchain-free install path on a stock Python.
• A .gitattributes keeps every checkout LF: Git for Windows defaults to autocrlf, and bash cannot run a CRLF script. The nine ST vendor files that were stored with CRLF are normalised to LF in their own commit (line endings only, git diff --ignore-cr-at-eol is empty), so nothing gets rewritten later on an unrelated edit.

Note: the vast majority of this diff is the nine ST vendor files under board/stm32h7 going from CRLF to LF for the .gitattributes change, in their own commit (9 files, 54,251 lines each way, line endings only: git diff --ignore-cr-at-eol is empty for it). The actual change is the other 10 files, +66/-16.

Tested on Windows: the firmware and libpanda build and sign with the mingw tools from an MSYS2 CLANG64 shell, and panda's own ./test.sh runs green there in 64 s (the firmware for all three boards and libpanda build and sign, ruff passes, and pytest passes all 9 tests, the three misra mutation cases included, about 50 s each in parallel); tests/usbprotocol/test_comms.py passes against the DLL (5/5), which is the packet-layout check; this repo's workflow on this PR, including its existing windows-latest pip package job (the new Windows ./test.sh entry takes about 3.5 min of the job's 10); and openpilot's full unit test suite on its Windows CI job, which builds this branch: commaai/openpilot#38810. The Linux and macOS builds are unchanged, confirmed by the same workflow.

Draft: waiting on commaai/dependencies#107. The Windows CI entry installs comma-deps-gcc-arm-none-eabi and comma-deps-cppcheck for win_amd64 from PyPI, which that PR publishes on merge. Until then the last commit, titled TEMP and marked --- TODO REMOVE AFTER DEPENDENCY PR MERGES ---, points uv at a GitHub release of the same wheels built from that PR's branch on my fork, so the entry runs green here meanwhile. That commit is dropped and this PR marked ready once the wheels are on PyPI; nothing else in it changes.

This PR is part of a larger series of work bringing support for Windows to openpilot:

• rednose: os: add support for windows rednose#61
• opendbc: os: add support for windows opendbc#3724
• panda: (this PR)
• msgq: os: add support for windows msgq#709
• dependencies: os: add support for windows dependencies#107
• openpilot: os: add support for windows openpilot#38810

The dependencies PR goes first: the Windows CI entries here and in the other combined PRs install the wheels it publishes. Otherwise each PR merges independently; only the openpilot one depends on all of them.

The changes in this PR were generated by Claude Fable 5.1 but were human reviewed and fully tested end to end both locally and in CI.