Allow whitespace in JPQL and EQL JDBC escape literals.

[jewoodev]

JPQL and EQL tokenize JDBC date, time, and timestamp escape literals as single tokens, requiring the marker to be directly followed by the quoted literal. This rejects common JDBC-style forms such as {d '2012-01-03'}.

This change aligns JPQL and EQL parsing with HQL's *_ESCAPE_START structure. A shared JPQL, EQL, and HQL rendering path preserves both whitespace and no-whitespace forms, covered by the shared renderer TCK.

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[mp911de]

How about switching the general logic towards TIMESTAMP_ESCAPE_START (dateTime | genericTemporalLiteralText) '}' style as it is done in the HQL parser? The TIMESTAMP_ESCAPE_START is a bit strange though but it seems to require much less ceremony. What do you think?

[jewoodev]

Yes, I agree that this structure is cleaner. I updated JPQL and EQL to use *_ESCAPE_START ... '}' parser rules, following HQL's approach. Since JPQL and EQL do not have HQL's structured dateTime, date, and time rules, they retain their existing quoted-literal scope through generic_temporal_literal_text.

Splitting the composite lexer tokens also exposed a round-trip detail: the default renderer adds a space before }, while always rendering inline changes the existing no-whitespace forms. I therefore introduced a shared JDBC escape rendering path for JPQL, EQL, and HQL that preserves whether whitespace follows the marker. The shared renderer TCK now covers both forms for date, time, and timestamp literals.