Improved argument description for parameters originating from tuples

[dragomirtitian]

Improved argument description for parameters originating from tuples that were extracted from functions. (ie mapped functions).

If the function parameters come from a tuple extracted from function parameters, then the signature help now provides the same information as the quick info. This means that if the tuple was extracted from a function we will now have the same names for the parameters as in the original function.

Ex:

function fnTest(str: string, num: number) { }
declare function wrap<A extends any[], R>(fn: (...a: A) => R) : (...a: A) => R;
var fnWrapped = wrap(fnTest);
fnTest(/*1*/) // At 1 - fnWrapped(str: string, num: number): void instead of function fnTest(...a: [string, number]) : void

Implementation notes:

1. I added getExpandedParameters to TypeChecker but marked it as internal so as not to impact the public API. This function might however be useful for clients of the API. Let me know if I should remove the internal.

2. If the argument of the mapped function is a single rest parameter the name of the parameter is not preserved in the quick info. Since this fix uses the same function as quick info (getExpandedParameters) it will suffer from the same issue.

function fnTestVariadic (...num: number[]) { }
var fnVariadicWrapped = wrap(fnTestVariadic);
fnVariadicWrapped() // fnVariadicWrapped(...a: number[]): void instead of fnVariadicWrapped(...num: number[]): void

This seems to be caused by the fact that the signature parameters will just have the rest parameter (...a: num[]) not a tuple with the rest (...a: [...number[]]).

This could be the topic of a different issue.

3. If the parameters do not originate from a function (ex: function fnTest3(...a: [number, string]) { }) the quick info shows a signature with the tuple spread to several parameters and an index added (function fnTest3(a_0: number, a_1: string): void ) this will also now be shown by the signature help as well. While this does not seem like a great improvement at least it is consistent.

Fixes #26563, #28127, #29514

[dragomirtitian]

On a personal note, this issue has been bugging me since 3.0, hope it gets merged :)

[dragomirtitian]

@RyanCavanaugh Is there anything blocking this PR and anything I can do to move it along? Or is it just a matter of time and priorities and someone will get to it when they get to it :) ?

[ahejlsberg]

@dragomirtitian Added a few comments in the code. If you update the PR we'll get it merged.