Adding a hook for post-processing generated queries

[s-mcqueen]

Is your feature request related to a problem? Please describe.
We face an internal requirement where we need the ability to modify queries generated by Cube before they are executed on the data source. We can imagine other use-cases for query post-processig, but our specific use-case is appending a SQL-comment for upstream logging purposes.

Hypothetical example, if Cube generated this query from a request:

SELECT 1;

then we may want to modify it with the securityContext before it reaches the Driver:

-- trace_id: 553bbd06-5695-4281-90b8-a54c82fcf58f
SELECT 1;

Describe the solution you'd like
The interface we are imagining is a new hook in the cube.js configuration file that provides a general-purpose way to do this:

module.exports = {
  queryPostProcess: (generatedQuery, { securityContext }) => {
    const traceId = securityContext?.['special_trace_id'] || 'unknown';
    const queryWithComment = `-- trace_id: ${traceId}\n${generatedQuery}`;
    return queryWithComment;
  }
};

Unlike queryRewrite, this hook would get called called after the query is generated/compiled by Cube and would operate on a string. This call could potentially make sense somewhere inside of CompilerApi.getSql before the final return or in the schema-compiler code, although surely the maintainers know better than me!

Describe alternatives you've considered
We could implement a custom driver to do this where we setup the driver per-request using something like this: https://cube.dev/docs/product/configuration/advanced/multitenancy#multiple-data-models-and-drivers. Basically we could write a StripeTracePrestoDriver.ts which is dynamically configured on each request to append a request-specific id from the securityContext each time right before execution. However:

1. A custom drivers feels like the wrong place to do this, especially when post-processing queries seem likes functionality that would be widely useful to other Cube users, perhaps for adding SET statements.
2. Using "multi-tenancy" Cube features just to dynamically set some context on the Driver to append to the SQL seems hacky.
3. We'd rather use the standard set of drivers (the Presto driver in our case) rather than maintain a special fork.

Additional context
We (@stripe!) would be happy to make this change and open a PR to solve this problem if Cube maintainers are supportive of this feature.