Turbopack: read block-scoping support during codegen (#101157)
### What?
`supports_block_scoping` is now queried during code generation instead
of during module analysis.
- `EsmModuleItem::code_generation` reads it from the chunking context's
environment, like `supports_arrow_functions` and the ESM/CJS externals
checks.
- The eager reads in `analyze_ecmascript_module` and in tracing-mode
`cross_module_constants` are removed, along with the
`supports_block_scoping` argument/field threaded through `create_graph`,
the graph `Analyzer` and `EsmModuleItem`.
### Why?
The value is only used in one place: choosing `const` vs `var` when
codegen lowers `export default <expr>`. Reading it before analysis made
the analysis task depend on the target environment's runtime versions
for no reason, and the tracing-mode read was never used at all (tracing
doesn't generate code).
The value now comes from the chunking context's environment rather than
the module's compile-time-info environment. For Next.js these are the
same: the client, server and edge chunking contexts are built from the
matching compile-time-info environments.
### How?
Output is unchanged. Existing snapshots cover both branches:
`swc_transforms/preset_env` (`chrome 41`, emits `var`) and
`preset_env_modern` and others (emit `const`).
Verification:
- `cargo test -p turbopack-tests --test snapshot`: 136 passed, no
snapshot changes. Temporarily forcing `const` made `preset_env` fail, so
the codegen-time read is exercised.
- `cargo test -p turbopack-ecmascript`: 618 passed.
- `cargo clippy --all-targets -p turbopack-ecmascript -p turbopack-tests
-- -D warnings` (includes the analyzer bench call sites).
<!-- NEXT_JS_LLM -->
<!-- fleet 32edbb43-1c4c-4771-9ee6-ee7b7dd5661d -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Luke Sandberg <210140+lukesandberg@users.noreply.github.com>
