[FEATURE]: Support multiple "drizzle" schema's on single database

### Describe what you want

I have a monorepo with multiple apps, micro-services and packages.
All node-based microservices use a single database, as hosting a database per service is to much overhead.
Each of the node-based microservices has a drizzle instance/folder with its own drizzle schema (including a postgres schema named after the name of the microservice), migrations / migration history, drizzle folder.

However, when starting from a fresh database. It's not possible to execute a migration for all services.
Only the first one is applied, the others are ignored as the "drizzle" schema already exists in the database after the first migration.

```
auth-service-1 | {
auth-service-1 | severity_local: 'NOTICE',
auth-service-1 | severity: 'NOTICE',
auth-service-1 | code: '42P06',
auth-service-1 | message: 'schema "drizzle" already exists, skipping',
auth-service-1 | file: 'schemacmds.c',
auth-service-1 | line: '128',
auth-service-1 | routine: 'CreateSchemaCommand'
auth-service-1 | }
auth-service-1 | {
auth-service-1 | severity_local: 'NOTICE',
auth-service-1 | severity: 'NOTICE',
auth-service-1 | code: '42P07',
auth-service-1 | message: 'relation "__drizzle_migrations" already exists, skipping',
auth-service-1 | file: 'parse_utilcmd.c',
auth-service-1 | line: '209',
auth-service-1 | routine: 'transformCreateStmt'
auth-service-1 | }
```

I assume drizzle-kit / drizzle-orm sees the migration history, which is unrelated to the migration of the second service and nothing is done. I assume, I am in need of a configurable drizzle-schema name, per microservice.

Is that something that is planned :)? Any ideas for a workaround for now? (Apart from hosting multiple databases).
Putting the database configuration in one separate package, would trigger a rebuild of all services in case a database change is done for one service in my CI pipeline...

---
While writing this, I came up with the tought to put the "out" folder in the drizzle config, to a common folder.
That would join the migrations I assume. Will test that as a workaround.