While working on #58243, a community member asked if we could label the tuple we use to properly type arguments to the next() methods of iterators and generators. A brief experiment showed that directly labeling the tuple element resulted in the creation of thousands of new types in some tests since iterator/generator instantiations would produce new named tuple elements since named tuple elements are cached far less frequently.

An alternative to that approach would be to use an additional source for the label when the label comes from a rest parameter whose name is actually an ArrayBindingPattern:

declare function a(...args: [] | [number]): void;
a(1); // quickinfo shows `(args_0: number)`

declare function b(...[value] : [] | [number]): void;
b(1); // quickinfo now shows `(value: number)`
      // quickinfo previously showed `(__0_0: number)`

Since this is merely treated as an additional labeling source, there is no need to synthesize additional types for named tuple elements.

This also improves label inference in other cases such as elision and object assignment pattern elements:

declare function a(...[x, , z]: [number, number, number]): void;
a(1, 2, 3); // quickinfo shows `(x: number, arg_1: number, z: number)`
            // previously showed `(__0_0: number, __0_1: number, __0_2: number)`

Related #58243 (comment)

Fixes #56289
Closes #57619