AsyncLocalStorage for query options

[IlyaSemenov]

As per #303, we have an option to override log settings inside a certain (sub-)transaction. I believe this is incorrect coupling; I am now in need to disable logging for a certain execution path without having to use transactions.

I propose to decouple log option from transaction AsyncLocalStorage to an individual local storage with its own life cycle, and something like

await db.withOptions({ log: true}, async () => {
 // all queries will be logged here
})

This has a potential to store more options. For example, as I elaborated in #642, it would be great to have a wrapper that binds db.options.schema into unbound raw-sql refs. Then, we could do:

await db.withOptions({ schema: currentTenant.schema }, async () => {
 await doWork()
})

async function doWork() {
 // this will automatically fetch from `tenant.table`
 await db.query`SELECT * FROM ${db.ref('table')}`
}

[romeerez]

Agreed for the log option, it should be relatively easy to do.

I'm going to keep using the same local storage for that, it's just implementation detail, for micro-optimization reasons.

As for handling the schema option here, I think it's fine as well. This is a default schema for tables, it won't override if the schema is set in a specific table class with schema = 'customSchema', but it should be used for all tables that don't state their schema explicitly. And let the db.ref use it as well.

[romeerez]

Ready: I added $withOptions.

It's using the same local storage, I renamed it from db.internal.transactionStorage to db.internal.asyncStorage.

It supports log: boolean and a schema: string | (() => string).

The schema won't be applied if it's already set in ORM's config or on a table level.

And it cannot be applied for db.ref('table') because I primarily thought about ref as a tool for referencing columns, not tables.

There is also sql.ref, let's add sql.table for the table purpose? Then it could be prefixed with the schema.