fix(exasol): fix TO_CHAR parsing leaking canonical datetime format tokens

[nnamdi16]

What motivated this PR?

When transpiling Exasol SQL that uses TO_CHAR with datetime format strings to other SQL dialects using SQLGlot, canonical datetime tokens (e.g., %a, %A) can appear in the generated SQL. These tokens are internal representations and are not valid syntax in target dialects, leading to execution errors or invalid SQL output.

---

What was incorrect in the existing logic?

The Exasol parser canonicalises datetime format strings inside TO_CHAR expressions. However, when generating SQL for a target dialect, these canonical tokens are not remapped to the target dialect’s format model.

For example:

SELECT TO_CHAR(CAST('2024-07-14 02:40:00' AS TIMESTAMP), 'DY')

When transpiled from Exasol to Oracle could incorrectly produce:

SELECT TO_CHAR(CAST('2024-07-14 02:40:00' AS TIMESTAMP), '%a')

instead of the valid Oracle format 'DY'.

This behaviour only occurs for TO_CHAR expressions; other datetime formatting paths remain correct.

---

How does this PR resolve the issue?

This PR updates the Exasol TO_CHAR parsing logic so that canonical datetime tokens are correctly remapped when generating SQL for other dialects.

The implementation:

• Ensures that all canonical datetime tokens are converted to the corresponding target dialect format during SQL generation.
• Limits the change to TO_CHAR parsing in the Exasol dialect; other datetime formatting paths are unaffected.
• Preserves existing Exasol behaviour and syntax for native queries.

---

Documentation and semantic notes

• Only affects TO_CHAR expressions with datetime format strings.
• No changes are made to the SQLGlot AST structure beyond correctly tracking canonical tokens for remapping.
• Target dialects now receive valid, dialect-specific datetime format strings.
• This improves correctness for Exasol → other dialect transpilation without breaking existing Exasol queries.