Is your feature request related to a problem? Please describe.

It's not uncommon for a single application to need to use multiple different database connections. Common use cases include using a different connection for executing DB migrations vs rest of the app and multi tenant setups (in the "one DB per tenant" setup that is). Perhaps less common, but still found in more complex apps are cases where certain separate connection is used for a subset of features (logging, event tracking, etc. ; specialized solutions exist, but can be implemented in DBs as well).

While MikroORM's RequestContext supports this, the mikro-orm.config.ts file does not, meaning such setups are not easily manageable by the CLI. And beyond that, framework integrations should also be allowing multi database setups, and ideally type the driver properly, but they can not easily do that without more user input, making integration more painful.

Describe the solution you'd like
Allow mikro-orm.config.ts file to export an array of ORM config objects, in addition to a single ORM config object.

Let the CLI specify a config name in a separate option to operate it on, looking it up at the already existing "name" option. It would be error in CLI if names repeat in the array. Default to the name "default" for compatibility with the RequestContext.

Having this supported by the CLI and ConfigurationLoader, and documented as such will in turn enable framework integrations to rely on it for multi database setups. In frameworks that have separate type gen steps (like Nuxt and Astro), integrations with MikroORM can generate the appropriate types for all the entity managers based on that config. Framework integrations (in general, i.e. also including f.e. NestJS) may further expose a proxy of the config object to enable lazy loading of additional configs, which would be a big blessing in a multi tenant setup.

Describe alternatives you've considered

In the case of the CLI, we can already specify a custom config file path, which means one can have a config file per connection.

In the case of framework integrations, they need a path to a config file that may also be an array of paths to config files instead... or some custom map of config objects... but relative file path lookup in general is a vector of complexity for users ("what is that path relative to? does that file even exist at the time I'm trying to read it?"), so having a fixed location where all the config is found would be easier on everybody.

Additional context

I've been playing around with trying to make a sample app with Astro, and while I'm already successful, I wanted to make it as simple as adding an astro "integration" that searches for the config at build time, and takes care of providing a forked EM wherever the request is available. Further, I previously made a MikroORM Nuxt module, and I already got a feature request about it not requiring driver imports everywhere, which is a reasonable request that I can accomplish (in a similar fashion to Astro)... If it wasn't for the fact that multiple connections are a thing, meaning some user level complexity is still required.

I think I can do both Nuxt and Astro integrations that are able to infer more and lead to a more pleasant DX... But I do need the multi DB setup somehow, as I will need it in my own applications (in my case, we have a dedicated server for logging... and also dedicated credentials for migrations).