New methods: filter, indicesWhere, reverseOnto

Also, add deep matches to tests

This is a general improvement, independent of named tuples.

Use the sugared representation, not the raw NamedTuple type tree.

Subclasses of Selectable can instantiate Fields to a named tuple type
that provides possible selection names and their types on instances of the type.

See: https://contributors.scala-lang.org/t/expanding-changing-selectable-based-on-upcoming-named-tuples-feature/6395/5

I usually try to avoid explicit returns, but here they do make the
code easier to read.

The selectDynamic call could already have influenced type variables
in the expected type before we wrap it in a cast.

Need to pass in the right expected type to the typedDynamicSelect.

NamedTyple.From should be the identity for named tuple arguments

inMode is useful, but its name is can easily be misinterpreted. Hopefully,
withModeBits is better.

Fixes rebase breakage where inMode was made private, but needs to be public since
it is now used in Desugar.

Strip NamedArgs instead when making a term/type classification of tuples.

The previous classification of NamedArgs as terms or types broke the completion test suite.
It seems that completion relies on NamedArgs being neither types nor terms. And in a sense,
that's correct. They are not.

It now work with just named tuples, no other extensions are needed.

Co-authored-by: Dale Wijnand <[email protected]>

We need to go through an explicit pattern match to drop the names.

… pattern match

The pattern matcher selects tuples up to 22 using _1, _2, ... But if the scrutinee is a named
tuple this only works if it is cast to a regular tuple first.

as is the case for `Concat`

to only require being defined on the element types.
Similar to what we have for `type FlatMap`

and refine `type IndexOf` doc

This is for the same reason as we changed
`type Head[X <: NonEmptyTuple] = ...` to
`type Head[X <: Tuple] = ...`

Also, this is no more unsafe than the other operations already defined for all tuples.
`drop(1)` for example was always defined, even though `tail` wasn't.

The tuple term level definitions were not being tested before

Keep only the changes we need for making NamedTuple work properly.
We still keep operations Contains and Disjoint in Tuple and make Reverse standard.

We remove or amend tests that relied on the changes to Tuple. No
tests about NamedTuple's are affected.

If we add it as is now, we will *not* be able to add the bound in
a future release. It is best to leave it completely undefined. The
typer is happy to ignore the case where it does not exist at all.