Adapt generic tuples to be able to access members

[nicolasstucki]

Fixes #14215

With this change, the _N members of TupleN can be selected on generic tuples of known arity. This also includes the Tuple2.swap method.

[nicolasstucki]

This still does not fix the issues when inlining (#14209), but it seems to go in the right direction to fix that issue as well.

[SethTisue]

Curious whether the restriction to known arity was just a matter of ambition-level-at-present, or whether a design decision has been made that x._1 here not only doesn't, but actually shouldn't work:

scala> def foo[T <: Tuple](x: Int *: T) = x(0)
def foo[T <: Tuple](x: Int *: T): Int
                                                                                                    
scala> def foo[T <: Tuple](x: Int *: T) = x._1
-- [E008] Not Found Error: -----------------------------------------------------
1 |def foo[T <: Tuple](x: Int *: T) = x._1
  |                                   ^^^^
  |                  value _1 is not a member of Int *: T
  |
  |                  where:    T is a type in method foo with bounds <: Tuple
1 error found

In a classroom, I'd have trouble explaining to a student why (0) and ._1 aren't exactly the same, in every context.

[odersky]

I think the answer is that we should deprecate the selectors and only use indexing.

[SethTisue]

I think the answer is that we should deprecate the selectors and only use indexing.

Hmm, interesting.

Dale points out that tuples are products and that product elements must have names. But I guess any further unpacking of the implications of your suggestion should move to a new ticket.

related: #15253