option to speed-up local check build - #2071

Profiling the real build logs showed Step 3 is 62-90% of a slim build,
and inside it resolve is 1.5% while install is 96.8%. The built slim
distro carries 38,590 .pyc for 38,590 .py: pip byte-compiles every
module, serially, and that is most of the 13.6 minutes.

Most local builds only exist to produce a pylock or pre-check the final
size, and do not need .pyc at all. So make it a choice, per build:

    bytecode = "pip"         # default: inline, exactly what ships today
    bytecode = "none"        # no .pyc -- throwaway builds
    bytecode = "parallel"    # --no-compile, then compileall over every core
    bytecode = "parallel-4"  # ... capped at 4 workers

Non-default modes pass --no-compile to pip and, for parallel, run one
compileall pass with the *target* interpreter after Step 4, so the
patched sources are the ones compiled. Compile failures stay non-fatal,
matching pip: some packages ship modules that will not compile here.

Measured on the build machine (8 cores, Defender realtime on), 2520-file
sample: compileall -j1 45s cold / 36s warm, -j0 18.7s. About 2x rather
than 8x, because the work is partly I/O-scan-bound rather than CPU-bound
-- worth having, but not the whole story. Antivirus exclusions for the
build trees are likely a bigger lever and are the user's call.

Default is unchanged, so release builds keep shipping .pyc exactly as
before. A typo in the TOML raises rather than silently shipping none.

tests/test_build_options.py covers the mode parsing, and winpython/** is
added to the CI path filter so build changes now run the suite. Wiring
verified end to end: existing TOMLs still yield --bytecode pip, a TOML
setting it yields it for that flavor only, the value survives
build_winpython's parser, and the emitted compileall command targets the
right interpreter and site-packages.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>