synthesize mirrors for small generic tuples

[bishabosha]

finally, summon[Mirror.Of[Int *: String *: EmptyTuple]],

has the nice benefit of also being possible to summon a mirror that is derived from the MirroredElemTypes of another mirror

fixes #14127
fixes #7049

[bishabosha]

to fix MiMa we probably need to exclude the scala.Tuple and scala.*: companion objects from themselves becoming mirrors

Edit: I don't know why the erasure of Tuple.apply would change due to this PR?

Perhaps it depends on either tupleArity or tupleElementTypes which I modified

[bishabosha]

I think it'd probably be cleaner to make a variant of classSymbol that reduces to some union of classsymbol/pseudoGenericTupleClass that is ran first, and then in acceptable check that each part reduces to the same pseudoclass

[bishabosha]

@odersky I ask here for advice because the issue here is that typically we would extract a class symbol from a type, and judge if that class symbol is a generic product, but we can't make a class symbol for a generic tuple type.

an alternative would be to mirror the classSymbol operation but only extract to a Option of a generic tuple, (rather than the fusion here)

[bishabosha]

I have simplified the way to extract the tuple proxy, with a trade off that it traverses the type twice if necessary

[pweisenburger]

Edit: I don't know why the erasure of Tuple.apply would change due to this PR?
Perhaps it depends on either tupleArity or tupleElementTypes which I modified

It probably does. In PR #14586, I found the following:

def test0: Int *: EmptyTuple.type = ???  // erases to `Tuple1`
def test1: Int *: EmptyTuple = ???       // erases to `Product`

It doesn't seem like these types should be erased differently but they are. That PR also fixes treating EmptyTuple and EmptyTuple.type differently in general (except for erasure for binary compatibility).

[bishabosha]

It doesn't seem like these types should be erased differently but they are. That PR also fixes treating EmptyTuple and EmptyTuple.type differently in general (except for erasure for binary compatibility).

Thanks for noticing these cases - I had a look after I made the comment and traced it earlier to the implementation of tupleArity which does not treat the widened EmptyTuple$ as EmptyTuple.type, which this PR addresses to make them be treated the same

[bishabosha]

Last changes pushed were to treat only *: as a generic tuple, before I captured arguments of TupleN types which had some problems with type parameters.