Add IsNamedTuple compiletime op

[bishabosha]

This reuses the NamedTuple type extractor underneath, and is careful not to reduce when the scrutinee of a match type.

The use case is to be able to define a recursive algorithm such as "does this named tuple type have a substructure equivalent to this other named tuple type?"

e.g. the status quo in #22422 is that Int can not be compared to case NamedTuple[ns,vs] and (x: Int, y: Int) can not be compared to case Int. With this compile time op you can have branching logic.

I should probably add an example of the recursive algorithm as a test. - but initial testing in the repl is good result:

scala> type IsNamedTupleForward[X] = NamedTuple.IsNamedTuple[X] match
     |   case true => true
     |   case false => false
     | 
                                                                                                              
scala> summon[IsNamedTupleForward[(x: Int, y: Int)] =:= true]
val res6: true =:= true = generalized constraint

scala> summon[IsNamedTupleForward[Int] =:= false]
val res8: false =:= false = generalized constraint

scala> case class Person(name: String, age: Int)
// defined case class Person

scala> summon[IsNamedTupleForward[Person] =:= false]
val res7: false =:= false = generalized constraint

also for bonus the OptFrom:

scala> type FieldNames[X] <: Tuple = NamedTuple.OptFrom[X] match
     |   case Some[nt] => NamedTuple.Names[nt]
     |   case _ => EmptyTuple
     | 

scala> summon[FieldNames[(x: Int, y: Int)] =:= ("x", "y")]
val res3: ("x", "y") =:= ("x", "y") = generalized constraint

scala> summon[FieldNames[Person] =:= ("name", "age")]
val res4: ("name", "age") =:= ("name", "age") = generalized constraint

scala> summon[FieldNames[Int] =:= EmptyTuple]
val res5: EmptyTuple.type =:= EmptyTuple.type = generalized constraint

fixes #22422

[bishabosha]

if you enable tracing then this return starts to warn, due to the surrounding trace call, so this is here

[bishabosha]

if this were rejected - i believe that the use case of a substructural check could be relegated to an implicit evidence generated via macro (provided the macro api has suitable api for manipulating named tuple types)