GeezerVison

During tests for integration of the JSqlParser into the https://github.com/Open-J-Proxy/ojp we found some limitations on how FOR UPDATE is interpreted.
This PR adds three things:

Grammar fix — multi-table OF clause: FOR UPDATE OF t1, t2, t3 was previously broken (only a single table was accepted), causing a ParseException. This affected any SELECT, not just subselect scenarios — the for_update07.sql oracle test just happens to use a subquery in FROM.

Grammar fix — ORDER BY after FOR UPDATE: Some Oracle SQL puts ORDER BY after FOR UPDATE (non-standard ordering). This also caused a ParseException before (for_update08.sql).

ForUpdateClause API class: A convenience object returned by getForUpdate() that aggregates all lock state (mode, table list, wait options) into a single object, useful for programmatic inspection in read/write routing scenarios as described in the problem statement. It's additive — all the pre-existing getForMode(), getWait(), isNoWait(), isSkipLocked() methods still work unchanged.