fix(3410): preserve type arguments in hover for qualified names

[a-tarasyuk]

Fixes #3410

[weswigham]

This is technically an abuse of the AST - ExpressionWithTypeArguments is only naturally parsed in the context of class extends clauses, however it's probably fine for making hover match up better, and AFAIK nothing in the emit pipeline relies on ExpressionWithTypeArguments only appearing in class extends positions (I would feel better about this with a strong type system, but alas).

Instantiation expression type arguments normally live exclusively on the TypeQuery itself, which is something we need to double check isn't being doubled up on here; if we go to put an ExpressionWithTypeArguments into a TypeQuery in the node builder, we probably should swap the type arguments up into the type query. I'll also be surprised if you don't need to update failing fourslash tests.

[ahejlsberg]

This is technically an abuse of the AST - ExpressionWithTypeArguments is only naturally parsed in the context of class extends clauses

That used to be the case, but these days we parse ExpressionWithTypeArguments for instantiation expressions, so they can definitely occur in regular expressions.

[weswigham]

Expressions, yes, not usually arbitrary expressions within type nodes, though - only at the end of a typeof query. declare const x: typeof Something<string>.Other does not parse (yet is what we're emitting here), but declare const x: typeof Something<string> does.