This PR introduces strict-mode compatibility diagnostics to help developers safely migrate modules that will be executed in strict mode and/or emitted as ESM.

Rel#17121

What kind of change does this PR introduce?

• New plugin:StrictCompatibilityPlugin
  • Hooks into the JavaScript parsing pipeline and reports only strict-mode-relevant issues
  • Leveragesparser.isVariableDefined for exact scope checks
  • Emits diagnostics via module.addWarning / addError depending on strictCompatibility mode
• Configuration/schema/types:
  • Adds strictCompatibility to module.parser.javascript schema and d.ts:
    • "warn" | "error" | false
  • Applied in WebpackOptionsApply (no-op unless configured)

Detection (ECMA-262 Annex C)

Strictness-sensitive patterns are classified into:

• Syntax-incompatible in strict mode (treated as build errors or parse failures)
  • with statements
  • delete on unqualified Identifier (delete x)
  • Duplicate function parameters
  • Using eval/arguments as identifiers
  • Legacy octal numeric literals (e.g., 0644) — handled by Acorn as parse errors in strict mode
  • Legacy octal and non-octal decimal escape sequences (e.g., "\123", "\8", "\9") — handled by Acorn as parse errors in strict mode
• Semantic/runtime-impactful (surfaced as warnings by default)
  • arguments.callee / arguments.caller
  • Accessing Function#caller / Function#arguments
  • Top-level this (becomes undefined in strict mode)
• Assignments and updates (errors in strict mode)
  • Assignment to undeclared identifiers (detected via parser scope)
  • Assignment to read-only globals: undefined, Infinity, NaN
  • Assignment/update of eval or arguments
  • Catch parameter named arguments

Note: Some of these are rejected by Acorn in strict mode before plugin hooks (they appear as Module parse failed), which is expected and relied upon.

Did you add tests for your changes?

yes

Does this PR introduce a breaking change?

no

Might be good to write docs?