FINERACT-2735: Validate datatables order input on actual columns

[terencemo]

Description

Adds validation for the order query parameter on the datatables read endpoints (GET /datatables/{datatable}/{apptableId}, GET /datatables/{datatable}/{apptableId}/{datatableId}), aligning with the existing convention already used on the offices endpoint.

What changed

• order must reference a single column that exists on the target datatable, verified against the table's resolved column metadata.
• An optional ASC / DESC direction may follow the column name (case-insensitive).
• Column names needing demarcation (e.g. containing spaces) can be quoted with double quotes or backticks — either style works regardless of backend, since output is always re-escaped using the correct dialect (PostgreSQL, MySQL, MariaDB).
• Multiple columns (comma-separated) aren't supported, matching the offices endpoint.
• Invalid or unrecognized order values are now rejected with a clear validation error instead of being passed through.

Why

Aligns datatables sorting with the simpler convention already used elsewhere, improves input validation, and removes ambiguity in how space-containing column names were interpreted.

Testing

• Unit tests in DatatableUtilTest: valid bare/quoted columns, direction handling, and rejection of unknown columns, malformed quoting, and multi-column input.
• Integration tests in DatatableIntegrationTest (validateOrderParameterOnDatatableEntryRead, validateOrderParameterOnDatatableManyEntryRead) covering both the single-entry and one-to-many entry-read endpoints end-to-end..
• Verified against MySQL/MariaDB and PostgreSQL.

Compatibility

Single-column, unquoted, no-space order values continue to work unchanged. Multi-column ordering or unquoted space-containing column names now require the quoting convention above.

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

Your assigned reviewer(s) will follow our guidelines for code reviews.