Avoid constructing empty extends clauses in hovers

[DanielRosenwasser]

Fixes #3506

[Copilot]

Pull request overview

Fixes a hover/quick info crash in the TypeScript-Go language server when expanding class declarations whose base type cannot be represented as a valid extends heritage expression (e.g., mixin constructors returning intersections).

Changes:

• Skip emitting an extends heritage clause when no valid ExpressionWithTypeArguments nodes can be constructed for the base types.
• Add a new fourslash test covering hover verbosity on a class extending a mixin constructor that returns an intersection type.
• Add the corresponding reference baseline for the new fourslash test.

Show a summary per file

File	Description
internal/checker/nodebuilder_hover.go	Filters out nil heritage expressions and avoids constructing an empty extends clause during hover expansion.
internal/fourslash/tests/quickinfoVerbosityClassWithMixinBase_test.go	New regression test exercising hover verbosity expansion for a mixin base returning an intersection.
testdata/baselines/reference/fourslash/quickInfo/quickinfoVerbosityClassWithMixinBase1.baseline	New expected hover output baseline for the added test.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

The comment says the expanded hover includes the class heritage clause, but the expected baseline output for verbosity level 1 shows class Derived {} with no extends .... Please update the comment to describe the actual intended behavior (e.g. that we omit an extends clause when we can't construct any heritage expressions) so the test remains self-explanatory.

Suggested change

	// including the class heritage clause for a constructor returning an intersection.
	// omitting an extends clause when no heritage expression can be constructed
	// from a constructor type returning an intersection.

[gabritto]

In light of the recent issues we've had in this same code path, I'm wondering if maybe the right thing to do here is to just print the heritage clauses as they exist in the declaration(s). I think we're not supposed to expand those, so I'm not sure anything is gained by reconstructing the heritage clauses from the base types, which potentially loses information that the declaration had...

[gabritto]

Could we somehow just print extends Mixin here?