fix: restore scope and export expression code generation

[joaodinissf]

Summary

Restores and tests two expression-generation behaviours in the scope and export DSL pipelines.

Nested arithmetic

isNumber() previously relied on resolveType(). That returns null for an arithmetic OperationCall, so an outer operation could misclassify a nested arithmetic expression and render it as a method call:

*(4 + 2, 3)

The compilers now recognize nested arithmetic operations recursively, producing valid Java such as:

(4 + 2) * 3

This was a real latent generation bug: existing repository models did not exercise nested arithmetic, so the malformed output had escaped CI.

Equality translation

The Xbase translator mappings for == and != implement value equality, while the scope and export string compilers intentionally emit Java identity equality.

The translators now leave these operators unsupported so generation falls back to the existing string compilers. Current production generation already uses that fallback for these expressions, so this is a defensive translator-contract correction rather than evidence of a live equality regression.

Both changes are applied symmetrically to scope and export.

Tests

Adds a shared expression-generation test harness with concrete scope and export test classes, registered in the existing aggregate test suite.

The tests cover:

• nested and recursively nested arithmetic;
• simple arithmetic and string-concatenation controls;
• the requirement that equality and inequality remain untranslated.

Before the fix, nested arithmetic failed in both compiler implementations and the equality translators violated the fallback contract. All six inherited tests pass after the fix.

Versioning

Bumps the scope and export bundles from 17.3.2 to 17.3.3 because both contain production-code changes.

Validation

• Scope and export regression tests pass.
• Checkstyle, PMD, CPD, and SpotBugs pass.
• The full aggregate suite executes the new tests successfully.