Fix special cases of kwargs + TypeVarTuple

[A5rocks]

Fixes #16522. This PR adds special casing for TypeVarTuple inference in the face of kwargs, though I believe the general case requires providing multiple possible constraints (e.g. "constraint a OR constraint b OR constraint C") which either isn't possible or I don't know how to.

This PR also fixes the subtyping of e.g. def f(a: int) -> None being a subtype of def g(*args: Unpack[tuple[Any, ...]]).

TODO:

• check if this impacts other issues (I think subtyping fix might)
  • Fixes Callables like operator.call produce arg-type error with callables that take *args: Unpack[Ts] and >= 1 keyword argument #16662.
• add a test case
• resolve conflicts

[A5rocks]

cc @ilevkivskyi since I saw your changes w/r/t typevartuples when glancing over the merge conflicts. Maybe you'll have an idea of whether this Any-tuple thing is worth anything.

[jakkdl]

With the simplification from removing Any-tuple this looks pretty damn clean. With no diff from mypy_primer I think we only need new tests and then it's pretty much ready to merge 🎉

[A5rocks]

I split off #17843 for the part of this PR I am certain is correct. I have some ideas on how to fix kwargs's presence with TypeVarTuple in the general case that I want to try out.

Turns out I can't split anything off because the two fixes need each other for any visible effect.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[jakkdl]

Would be lovely to get this merged, but it appears we've gotten merge conflicts that need resolved @A5rocks

[A5rocks]

I've made a better version of this at #18958