Try to instantiate TypeVars inside pt when possible

[noti0na1]

This PR improves type inference for functions with unknown parameter types when the expected type contains type variables within union types. Previously, the compiler would only attempt to instantiate top-level TypeVars, but now it recursively searches through union types (OrType) and flexible types to find and instantiate nested type variables.

[hamzaremmal]

At least, we should put AndOrType here to cover such cases:

def f[T, U](x: T & U): T = ???
val _: AnyRef => AnyRef = f(x => x)

[hamzaremmal]

@noti0na1 I've been working on this a bit before seeing this work and I see that we reached the same conclusion for where the fix should be. In my opinion, this approach constraints too much inference when using union (could be extended to intersections). If we have a lambda as a first parameter, we will basically already instantiate now the type parameters even if we can refine them later. For example, in this PR, we cannot do the following:

class Box[T]
val box: Box[Unit] = ???
def f[T, U](x: T | U, y: Box[U]): T = ???
val _: Any => Any = f(x => x, box)

I'm not sure yet how to find the best compromise to also make this work.

[hamzaremmal]

I would argue we should probably use stripNull for now for the sake of better compatibility with explicit nulls and without the side effect of too much instantiation of type variables. We can improve later type inference to cover more scenarios. It is better than #24230 in my opinion.

[noti0na1]

Even if we fix the inference issue, I don't we can keep Option.apply nullable, since it will still break the macro writer by users.

[hamzaremmal]

Even if we fix the inference issue, I don't we can keep Option.apply nullable, since it will still break the macro writer by users.

And they will have to migrate to it. That very specific thing should not be considered (again in my opinion) the blocker to have the right signature for Option.apply. Fixing inference is the most important part in that issue.