Fix Dependent types in TupledFunction

[TheDrawingCoder-Gamer]

Try to fix #21808

I NEED HELP! PLEASE HELP ME! I'VE NEVER DONE COMPILER STUFF BEFORE!

Current progress:
Fixed the bug, but now "tests/run/tupled-function-untupled" fails, probably because i updated the code incorrectly

YES, this code is a mess. I DONT KNOW HOW THE COMPILER WORKS! This is also a draft so I can get guidance on how to do this work properly.

[TheDrawingCoder-Gamer]

Ok I did locally fix that test, but now I made a new test to make sure that It can untuple dependent types, and I seemed to have found a bug in inference? Inference also discards dependent types:

object Test {
  def main(args: Array[String]): Unit = {

    val f2: (x: (Int, Long)) => x._1.type = (args: (Int, Long)) => args._1
    val g2: (x: Int, y: Long) => x.type = f2.untupled
    println(g2(1, 3L))

  }

  extension [F, Args <: Tuple, R](f: Args => R) def untupled(using tf: TupledFunction[F, Args => R]): F = tf.untupled(f)
}

-- [E008] Not Found Error: tests/run/i21808.scala:8:45 -----------------------------------------------------------------
8 |    val g2: (x: Int, y: Long) => x.type = f2.untupled
  |                                          ^^^^^^^^^^^
  |value untupled is not a member of (x: (scala.Int, scala.Long)) => (x._1 : scala.Int).
  |An extension method was tried, but could not be fully constructed:

Compiler SHOULD try to fill in [F, X <: (Int, Long), X._1] (or however its correctly written out) but instead tries to construct

 [F, (scala.Int, scala.Long), scala.Int]

and the compiler (correctly) rejects the attempt to untuple a dependent type into a non-dependent type

[TheDrawingCoder-Gamer]

new code is incorrect,
summon[TupledFunction[(x: T, y: T) => x.type, (x: (T, T)) => Tuple.Elem[x.type, 0]]] fails to compile due to a match error.

A large issue is that there is no good "standard" for selecting elements of tuples in scala. TupledFunction treats tuples specially and I feel like the compiler should definitely have more control over them, instead of relegating them to the stdlib. However, I don't really know of a good way to fix this