bpo-43224: Work around substitution of unpacked TypeVarTuple

[mrahtz]

Following up on the discussion in #31021 about how to handle substitution of TypeVarTuples, here's a first attempt at the solution Jelle suggested: when TypeVarTuples` are involved, don't perform the substitution at all, instead returning an object whose repr() reflects that.

(What Jelle actually suggested was to return a new _GenericAlias here. I've tested that too, and it seems to work fine, but I'm a bit wary about giving _GenericAlias too many hats to wear - as a newcomer to this codebase, I've struggled with how overloaded classes already are, making it predict what the effects of a change will be. Having said that, Jelle, I remember you mentioning you'd prefer to keep the number of classes in typing.py small, so if you think the tradeoff isn't worth it, I respect your judgement, and we can re-use _GenericAlias, coping with the extra functionality with extra documentation comments.)

The main alternative I'm aware of is the logic we cut out in b9b1c80 - about 200 lines of logic, and another 100 lines of tests. @serhiy-storchaka also has a partial solution in #31800, which could also be an option - making the substitutions only when it's easy, and otherwise falling back to the approach in this PR.

I've also pulled in @serhiy-storchaka's nice assertEndsWith helper from #31800 :)

@JelleZijlstra @pradeep90

https://bugs.python.org/issue43224

[JelleZijlstra]

Thanks! I think it's better to go with _GenericAlias, because otherwise we have to re-implement a lot of what that class does: pickle support, __eq__, __iter__.

The idea would be that this is a step towards a rule where we can say X[T] == _GenericAlias(X, (T,)), whatever X is.

[mrahtz]

(Closed since it looks like @serhiy-storchaka is insisting on going ahead with #31800.)