Issue implicit any in JS files on widened inferred types from initializers in binding patterns

[Andarist]

This is still imperfect because JSDoc types are still WIP. This just ports some of the missing logic and some of the adjustments made in microsoft/TypeScript#60083 .

This PR is an oddball so feel free to close this as it might be better to revisit this when JSDoc types are more complete. It already fixes a couple of baselines though.

[Copilot]

Pull Request Overview

This PR ports missing logic from #60083 to improve how JS initializers produce widened types and report implicit any in empty literals.

• Adds getWidenedLiteralTypeForInitializer to centralize literal widening.
• Extends widenTypeInferredFromInitializer to report and return any/any[] for empty literals in JS files.
• Updates binding-element handling to use the new helper.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

File	Description
internal/checker/checker.go	Introduces getWidenedLiteralTypeForInitializer and adjusts widenTypeInferredFromInitializer; updates binding-element call site.
testdata/baselines/reference/.../*.types	Updates expected baselines to reflect any/any[] instead of never for empty initializers.
testdata/baselines/reference/.../*.errors.txt	Adjusts error baselines to include implicit-any diagnostics for empty literals.

Comments suppressed due to low confidence (1)

internal/checker/checker.go:17022

• This change bypasses widenTypeInferredFromInitializer, which includes JS-specific implicit-any diagnostics for empty initializers. Consider calling widenTypeInferredFromInitializer here instead of getWidenedLiteralTypeForInitializer to preserve those diagnostics.

return c.addOptionality(c.getWidenedLiteralTypeForInitializer(element, c.checkDeclarationInitializer(element, CheckModeNormal, contextualType)))