Implement isinstance() in Starlark interpreter

[Steffeeen]

Description

This PR actually implements isinstance() in Starlark. Until now, isinstance() was only reserved in the lexer and parser but could not actually be used.

Motivation

Closes #27848.

Build API Changes

No

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: None

This should probably only be released together with all the other type system changes.

Open questions

These are questions that are still open from my side that I would like to get input on.

Should isinstance() require enabling type checking?

Currently, for this implementation work correctly it requires that the user either uses static or dynamic type checking as otherwise the TypeTagger is not run. The TypeTagger is responsible for resolving the Expression in the IsInstanceExpression to a StarlarkType (similar to CastExpressions). If the TypeTagger is never run the code currently throws a NullPointerException in Eval#evalIsInstance() because it expects the IsInstanceExpression to have a StarlarkType. This should probably be caught by the Resolver but it currently does not have access to the information of whether the user has enabled type checking. Another option would be to add an explicit check in evalIsInstance() and throw an error there. Alternatively, to avoid this problem entirely, we could just always run the TypeTagger. But I'm not sure if this may cause other issues.

More complex type narrowing logic?

I only implemented a basic matching against a few (in my opinion) common patterns of using isinstance() instead of a full evaluation of all possible combinations of and, or and not together with isinstance(). I don't think the more advanced cases warrant the additional complexity.

The code for this pattern matching is currently not really nice as it uses long conditional chains. The conditions cannot really be factored out because the IsInstanceExpression and Identifier are both needed in the body of the if block. IntelliJ suggests using a switch statement instead of the if-else chain, however that makes the code even more unreadable in my opinion.

Type aliases

As far as I could tell, type aliases are not yet resolved in the TypeTagger and as such they don't work in isinstance(). I added a unit test that tests type aliases in isinstance() but it is annotated with @Ignore for now.