Record the build and run conditions on Windows

[hsbt]

On Windows, RUBY_DESCRIPTION is the same for MSVC and clang-cl builds of one revision and for builds with different flags, and results also depend on power settings that ruby-bench does not control. Two result files from such runs cannot be told apart afterwards.

The result JSON now records build_config (CC, CFLAGS, CPPFLAGS and optflags from RbConfig) and run_conditions, which holds the applied affinity mask and priority class, the active power scheme, and the power mode overlay that Windows 11 applies on top of it. Nothing changes on other platforms.

Generated with Claude Code

[k0kubun]

I have a similar impression as #552 (comment) here too. Because it impacts all benchmarks, harness-common.rb should generally be as simple as possible. Also, because modules/constants/methods defined at top-level are visible on all objects and could interfere with benchmarks (through *_missing), it's generally nice to define less in that file, whether it's for Windows or not.

The series of recent PRs that are filed/merged don't seem to be made with that understanding, so I'd like to advise your agent that it should first attempt to implement things outside harness-common.rb (e.g. on the parent process like the wrapper command executed by run_benchmarks.rb) and then define things only for Windows as a last resort.

[hsbt]

Understood. harness-common.rb also loads macOS- and Linux-only code on every platform, such as ProcPidRusage, macos_resident_size and the getrusage path in get_maxrss. I'm planning to separate those the same way. Does that work for you?

[k0kubun]

Works for me too. FYI, now CI runs Windows as well #555 and I filed #556 to address one of the points I raised above.

[hsbt]

🆗 I tested my windows environment with #555. It seems fine and makes better benchmark for mswin. I will update this and #552 with this direction.