introduce "sticky session" concept for handling temporary tables

### Use case

Today, things like temporary tables rely on the same connection to operate. To ensure that today, we need to ensure we start the clickhouse client with `max_open_connections: 1` as per the docs, but that means down our application stack we need to keep 2 versions of clickhouse client:
* one for the default connection pool
* one that is a constructor to starting a new clickhouse client with `max_open_connections = 1` and a fixed sticky session.

### Describe the solution you'd like

This takes inspiration from the [`database/sql` Golang package and how they handle transactions](https://pkg.go.dev/database/sql#DB.BeginTx).

Basically, allow the `clickhouseClient` to hold a "sticky session" which can occupy the same connection pool (i.e. respect the same `max_open_connections`).

The API could look something like:
```js
const chClient = createClickhouseClient(...)

// All handled in the closure.
await chClient.execStickySession(async (
// maybe a different type that inherits the same ClickhouseClient types but indicates it is sticky?
chClient: ClickhouseClient,
) {
// automatically uses the same session id for the next 2 commands
await chClient.command(...);
await chClient.command(...)
})

// Or explicitly.
const stickySession = await chClient.startStickySession();
try {
...
} finally {
stickySession.close();
}
```

### Describe the alternatives you've considered

We're basically passing 2 different clickhouse clients down the stack now.