SONARPY-2229 Fix FP on S2201 when instantiating the result of a type call

[guillaume-dequenne-sonarsource]

This is admittedly a very naive approach to fix this FP.

However, I believe that this deserves a broader discussion, considering SONARPY-2013 to allow for easier manipulation of type predicates.
I also considered adding a proper PythonType#kind API to avoid checking for instances. However, I feel this can still be done later if the need proves real.

[Seppli11]

According to our discussion, I think it would make sense to change the type checks in TypeCheckBuilder to either check if a type is an instance of a or is a.
Since this PR is using isTypeWithName introducing this change for this method would make sense.

Maybe it also would make sense to align the behaviour of isInstanceOf, so that checking with isTypeWithName checks for the type and isInstanceOf if it is an instance of a type. Having (somewhat) uniform behaviour for the type checkers when it comes to union type would make the API easier to use. But this should probably be its separate PR.

[Seppli11]

I think extracting this condition into its own method would help readability as it can be named

[guillaume-dequenne-sonarsource]

(I removed the condition altogether)

[guillaume-dequenne-sonarsource]

According to our discussion, I think it would make sense to change the type checks in TypeCheckBuilder to either check if a type is an instance of a or is a. Since this PR is using isTypeWithName introducing this change for this method would make sense.

Maybe it also would make sense to align the behaviour of isInstanceOf, so that checking with isTypeWithName checks for the type and isInstanceOf if it is an instance of a type. Having (somewhat) uniform behaviour for the type checkers when it comes to union type would make the API easier to use. But this should probably be its separate PR.

Following our discussion, I instead added the isStrict option to the isSameTypeAsPredicate. I feel that we should indeed have a more global approach to dealing with "in an instance of" vs "is the exact type", but I feel it should probably be part of a more global refactoring (we'll have to clarify the public type checking API we want to expose eventually, I think it can be part of that).

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[Seppli11]

lgtm