Allow empty type applications for ParamSpec

[A5rocks]

Fixes #20571. @JelleZijlstra I somehow didn't realize this was something until I saw microsoft/pyright#11225, so I didn't put this as a test case last time...

[A5rocks]

I just realized in the pyright issue there, @erictraut thinks this should error (i.e. current behavior) rather than be accepted. (I just skimmed and realized that my last PR didn't address this case)

I think generally we should be forgiving and that this is justifiable by the PEP, but I would be OK if we want to discuss this more instead. The weak justification being just this:

By the rules defined above, spelling a concrete instance of a class generic with respect to only a single ParamSpec would require unsightly double brackets. For aesthetic purposes we allow these to be omitted.

And there being no reason that shouldn't apply for an empty Parameters.

[hauntsaninja]

The thing that is clearly a bug in pyright is the inconsistency between the class case and the type alias case.

I think the behaviour of this PR makes sense. This is the test case I used when I reviewed it (maybe worth adding?):

# flags: --strict
from typing import Callable

class Cls[**P]:
    def __call__(self, *a: P.args, **k: P.kwargs) -> None: ...
type TA[**P] = Callable[P, None]

def f(cls: Cls[()], vt: TA[()], vt2: TA[(int,)]) -> None:
    reveal_type(cls)
    reveal_type(vt)
    reveal_type(vt2)

    cls()
    cls(1)

    vt()
    vt(1)
    
    vt2()
    vt2(1)

[github-actions]

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