Add SYSTEM_USER to SQL92 unparenthesized function names

[thswlsqls]

Fixes #39099.

Changes proposed in this pull request:

• Add SYSTEM_USER to SQL92FunctionOption.UNPARENTHESIZED_FUNCTION_NAMES so it binds as a niladic function instead of a column.
• SYSTEM_USER is one of the four SQL-92 §6.8 user-value niladic functions (USER/CURRENT_USER/SESSION_USER/SYSTEM_USER); the SQL92 baseline dialect previously listed only three.
• Aligns with the MySQL and SQLServer sibling DialectFunctionOption implementations, which already include SYSTEM_USER.
• Consumer ColumnSegmentBinder.isUnparenthesizedFunction() reads this set via .contains() to classify a bare identifier as function vs column.

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.
• I have updated the Release Notes of the current development version. For more details, see Update Release Note

[terrymanu]

Summary

Review Result: Not Mergeable

Feedback Mode: Needs Discussion

Reason: Adding SYSTEM_USER to the function-name set is correct, but it does not fix the linked issue. On the latest PR head, SELECT SYSTEM_USER is rejected by the SQL92 parser before the binder reads this set.

Issues

P1 — The reported SQL does not reach this change

Problem: The new test verifies only that SYSTEM_USER exists in SQL92FunctionOption. An exact-head parser/visitor check still raises SQLParsingException for SELECT SYSTEM_USER.

Impact: The behavior described in #39099 remains unfixed, and the release-note claim is not yet accurate.

Discussion Needed: Please first confirm how bare SYSTEM_USER should be represented by the SQL92 parser and where its niladic-function classification belongs, then validate the complete parser-to-binder path.

Review Details

• Review Focus: Code Correctness Review; CI not reviewed by request.
• Reviewed Scope: All three changed files at head 3c464e35c8ec49ab41fb2fee024235f80416323c, plus the relevant SQL92 parser and binder path. The local file list matched GitHub.
• Not Reviewed Scope: GitHub Actions, the full Maven suite, and JDBC/Proxy E2E scenarios.
• Verification: SQL92FunctionOptionTest passed with 2 tests and 0 failures. A reviewer-run exact-head parser check confirmed that SELECT SYSTEM_USER still raises SQLParsingException.
• Release Note / User Docs: The release-note entry is present, but its claimed behavior is not yet implemented end to end.

[thswlsqls]

Confirmed. In the SQL92 grammar the SYSTEM_USER token is declared in SQL92Keyword.g4 but is not referenced by any parser rule — it is unreachable through columnName → identifier → (IDENTIFIER_ | unreservedWord) in BaseRule.g4 and is not in regularFunctionName. So SELECT SYSTEM_USER never produces a ColumnSegment and fails in the parser before ColumnSegmentBinder#isUnparenthesizedFunction reads the set; the binder-set entry cannot fix #39099. The existing niladic names (CURRENT_USER, SESSION_USER, USER) have the same gap. I'll move the fix into the grammar — make SYSTEM_USER reachable as an unparenthesized/niladic function via BaseRule.g4 — and add a parser-to-binder test that actually parses SELECT SYSTEM_USER.

[thswlsqls]

Implemented as promised: SYSTEM_USER is now reachable in the SQL92 grammar via unreservedWord, so SELECT SYSTEM_USER parses to a column segment that ColumnSegmentBinder classifies as a niladic function through the unparenthesized-function set. Added the parser IT case select_system_user_sql92 covering SELECT SYSTEM_USER.