Expose structured ORDER BY fragment parsing

[minleejae]

Consumers that assemble queries from independent sort specifications currently need to wrap fragments in a SELECT or retain them as opaque expressions. For example, DBeaver's ORDER BY handling uses CustomExpression for a sort fragment (pinned consumer code). A fragment API exposes the expression and sort flags directly, so callers can inspect and rewrite them through the ordinary AST.

Add CCJSqlParserUtil.parseOrderByElements(String) and its parser-configuration overload. Input such as COALESCE(score, 0) DESC NULLS LAST, id ASC produces a List<OrderByElement>; the input excludes the ORDER BY keywords. Null or empty input returns an empty list, and trailing tokens are rejected.

The existing ORDER BY clause now delegates to a shared element-list production. Column-type parsing and the new API also share fragment parser setup, fast/complex retry, full-input checking, and exception handling. Existing column-type behavior is preserved, and each invocation starts with fresh parser state.

Validation: full Java 17 Gradle check passes, including the zero-conflict JavaCC grammar gate, tests, formatting, Checkstyle, PMD, and SpotBugs. Tests compare fragments with complete ORDER BY clauses, exercise configured quoting and parameter indices, verify custom expression deparsing and round trips, and reject incomplete or trailing SQL.

[manticore-projects]

Mhhh, I don't like this. I believe I do understand the requirement: simpler access to certain fragments, the walking the AST is cumbersome. But instead of specific solutions, I wonder if a kind of "querying" might be the better and more comprehensive solution here. Like XSL for an XML, something like */WHERE[1]/EXPRESSION[*]. In fact, I drafted something crude like this in JSQLFormatter years ago.

Suggestion: lets put this on small flame for a while and focus on getting a 5.4 release out. And then craft a proper AST querying mechanism for this together.
(Unless it was really urgent for you, then we would just take that in and deprecate it later. Just let me know.)

[minleejae]

@manticore-projects
This isn't urgent for me. I agree that a general-purpose AST querying mechanism would be more useful in the long term, and I'd be happy to work on that together. Let's leave this PR on hold and focus on the 5.4 release first.