Normalize variadic tuples with reduced never element type to never

[Andarist]

an issue observed while investigating another one, see here

This solves an inconsistency problem that can be seen here (TS playground):

type Baseline = [...never];
//   ^? type Baseline = never

type Test<T extends unknown[]> = [...T];
type Input = [] & [string];
//   ^? type Input = never
type Result = Test<Input>;
//   ^? type Result = any[]

Baseline and Result should both be never.

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[Andarist]

Without this the code hits the last branch:

                else {
                    // Treat everything else as an array type and create a rest element.
                    addElement(isArrayLikeType(type) && getIndexTypeOfType(type, numberType) || errorType, ElementFlags.Rest, target.labeledElementDeclarations?.[i]);
                }

But a never type (and a reduced never type) don't have index types. So that getIndexTypeOfType returns undefined and the compiler ends up normalizing this to an anyType.

Note that getIndexTypeOfType leads to calling getReducedApparentType so this effectively just calls it a little bit more eagerly.

This also matches how getIndexedAccessTypeOrUndefined + getPropertyTypeForIndexType handle case like this:

type Test = ([] & [string])[number];
//   ^? type Test = never

Those functions also call getReducedApparentType and when the object type has TypeFlags.Never they return the object type itself. The small difference here is that I decided to return neverType. This seems like a better product of this normalization... but perhaps this should also return the type? The tests wouldn't mind this change (I checked).

An extra note: this could also be checked closer to the top of createNormalizedTupleType (where checkCrossProductUnion gets called) but it seemed me this extra branch here is easier to follow~.