Recognize compile-time constants in LoopConditionChecker

[eviaaaaa]

LoopConditionChecker currently handles literal loop bounds but rejects equivalent javac compile-time constants. Local constant variables can be reported as if they were mutable condition variables, while static constants, member selects, casts, and conditional constant expressions can stop analysis entirely. This causes the checker to miss genuine loops whose only changing-looking operand is actually constant.

Use javac's attributed constant value through ASTHelpers.constValue instead of inferring constants from modifiers or initializer syntax. Constant identifiers are ignored as condition variables, and otherwise unsupported expression kinds are accepted only when javac has assigned them a compile-time constant value.

This intentionally does not treat boxed constants, method-call initializers, mutable fields, or other runtime values as constants.

Fixes #5826

The tests were first applied without the production change. LoopConditionCheckerTest ran 12 tests with 2 failures: local/static constant bounds were not treated like literals, and member-select/cast/conditional constant expressions produced no diagnostic.

The regression tests cover local, static, and externally declared primitive constants; constant initializer, cast, and conditional expressions; and negative controls for boxed, runtime, and mutable values. They also verify that only the genuinely mutable variable is reported.

LoopConditionCheckerTest and the full core -am test suite pass. A full reactor clean install -DskipTests also succeeds.