Do not generate integer division warning after casting expression to integer

[romgerman]

Fixes #42966

I've added new flags variable which is needed to store behavior change flags for different purposes while going through AST. I thought that adding a new method argument, which would span multiple methods, is not ideal for adding one kind of check. And adding something like a context structure seemed too over-engineered.

[dalexeev]

I don't think adding flags is justified in this case. We do this with current_class and current_function variables, but I don't think it's the best coding style since it adds extra state. You could instead check the AST structure (whether one of the operands is an int(...) constructor call or a ... as int cast) before producing the INTEGER_DIVISION warning.

Also, I'm not sure this is a good shortcut to suppress the warning. As far as I remember, an int(...) constructor call always produces runtime code, even if the operand is already an int. A ... as int cast may or may not produce runtime code depending on the direction of the cast, but that's still pretty non-obvious to the user. It's not the same as "use underscores to suppress the unused local variable warning".

We probably don't need a shortcut to suppress this warning at all. Perhaps the warning itself is rather contradictory and exists only because of the non-obvious behavior of the division operator, and serves more to educate users than to prevent typical accidental errors.

[romgerman]

current_class and current_function do exist in parser class. Their existence is justified by the parser class. But this function call check is only needed in the context of the semantic analyzer. Yes, this adds an extra state but while going through an AST there is no other way to check where we are at (at least I'm not sure there is), there exists only one node at a time.

Regarding the performance concern, that's a valid point. I haven't read the compiler code, but looking at it now I can see that there is code generation for built-in type construction. So I guess it can add a little bit of an overhead when using int() to suppress the warning. Not sure if this PR should resolve both problems (the severity needs to be determined).

I'm not sure about the ... as int cast because you already have at least two variables of type int so explicitly casting them to type int adds almost as much visual clutter as adding warning_ignore annotation IMO (also the annotation disables a warning for a whole line and one may want to disable specific expression in a long formula). With the cast it's not obvious how you should write it: x / y as int or (x / y) as int or (x as int) / (y as int). Having a clear scope of the int() function is what adds clarity to the conversion.

How I see it:
I have written some code which has integer division in it. Godot have warned me about that. Now I ask myself if I am sure I want to make an integer division or was it an oversight. I come to conclusion that I'm sure that in this specific part in my code I want to do an integer division. And so I put int() conversion function around this specific part in my code.
Sounds pretty user-friendly and clear if I'm not missing something. And as for the comments, it felt like many people assumed that using int() function around an expression would suppress the integer division warning.

(I know there is a proposal for adding an integer division operator. It's a valid way of resolving this issue. But IMO if GDScript wants to stay simple and user-friendly it does not need an another operator.)