Port implicit any type arguments in JavaScript

[DanielRosenwasser]

This restores the behavior of filling in missing type arguments (and default type arguments set to {} and unknown) as any in JavaScript files.

It should fix the behavior in #1090, but and unbreaks JS code I've tested elsewhere where things like new Set result in a Set<unknown> instead of a Set<any>.

Some of this is already partially controlled by flags like noImplicitAny - however, I do wonder if we should consider adding another --strict flag for this behavior in JavaScript files. My intuition is that JS devs using checking and --strict do want the same behavior as TypeScript, and would opt in for tighter checking. The use of JS is circumstantial around their build needs/preferences, not a signal of whether they want looser checking.

Fixes #1090

[Copilot]

Pull Request Overview

This PR restores JavaScript behavior by treating missing or default type arguments as any instead of unknown or {}, improving interoperability with existing JS code (e.g., new Set infers Set<any>). Key changes include:

• Extending fillMissingTypeArguments with a JS file check to use any defaults in JS.
• Updating numerous baseline tests to reflect any defaults in JS contexts.
• Adjusting calls throughout internal/checker to pass the new isJavaScript flag.

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
internal/checker/relater.go	Pass JS context flag to fillMissingTypeArguments in relation logic
internal/checker/inference.go	Pass JS context flag to fillMissingTypeArguments in inference
internal/checker/jsx.go	Update JSX instantiation calls to include JS context flag
internal/checker/checker.go	Widespread updates to signature instantiation, default constructors, and type argument logic to use JS flag
testdata/baselines/reference/submoduleAccepted/...	Baselines updated to expect any defaults and altered error counts

Comments suppressed due to low confidence (1)

[DanielRosenwasser]

Minimal repro for the crash is

// @filename: foo.js
export class A<T> {}

export class B extends A {
    constructor() {
        super();
    }
}

I haven't fixed it in the latest commits, but I was in the neighborhood and found a few places I had missed (or might as well have cleared out some diffs)

[jakebailey]

Based on the diffs, this sure seems correct to me. I'm not sure if this stuff was intentionally removed or not, though, but I feel like this should be here. Maybe @sandersn has an opinion, however.

(Also, baselines need a reup.)

[jakebailey]

Hm, this is exciting; wonder how easy it'd be to fix this?