[ty] Detect generic `Callable`s in function signatures (#22954)
When we coerce a generic function or class constructor into a
`Callable`, the callable type remembers that it is generic:
```py
def identity[T](t: T) -> T:
return t
# revealed: ty_extensions.GenericContext[T@identity]
reveal_type(generic_context(identity))
# revealed: [T](t: T) -> T <-- note the [T] generic context
reveal_type(into_callable(identity))
# revealed: ty_extensions.GenericContext[T@identity]
reveal_type(generic_context(into_callable(identity)))
```
However, there is no easy way to spell a generic `Callable` type in
Python. The closest you can get is by defining a generic type alias:
```py
Identity = Callable[[T], T]
type Identity[T] = Callable[[T], T]
```
To get around this, there is a common heuristic that if a generic
function binds a typevar, but that typevar is only mentioned in a
`Callable` _in return position_, then it's actually the _callable_ that
binds the typevar, not the function. (And if that's the only typevar
mentioned in the function signature, the function ends up not being
generic at all.) This comes up very often in decorator factories, where
the factory function returns a decorator that is generic over one or
more typevars:
```py
def decorator_factory() -> Callable[[T], T]:
def decorator(t: T) -> T:
return t
```
Here, `decorator_factory` should not be considered generic; its
`Callable` return type is.
Note that this is true for PEP-695 typevars, too!
```py
def decorator_factory[T]() -> Callable[[T], T]:
def decorator[T](t: T) -> T:
return t
```
(This is one example where PEP-695 syntax is misleading! We can usually
assume that a `[T]` binding context makes the item that it's attached to
generic — and that we can determine this statically. But in this case we
can't! We have to analyze the function signature to see that
`decorator_factory` is not generic, even though it has a PEP-695 binding
context.)
Closes https://github.com/astral-sh/ty/issues/1136
