Allow specifying .fork() options for Request-Scoped EntityManager in the MikroOrmModule

[AlexBksiad]

Is your feature request related to a problem? Please describe.
Recently with the goal of using both Singleton-scoped event subscribers on the Entity Manager, as well as Request-scoped event subscribers, I ran into the issue where the MikroOrmModule's behavior is to copy the existing Event Manager when forking the Entity Manager, and there is no way to override this.

An example of where this might be useful is if you are using two event subscribers - one for creating outgoing webhook triggers when certain records get updated, and one for writing auditable events to a log which includes the current user's id.

The first subscriber would be globally scoped, and the second one would need to be request-scoped (to include the current user's id).

Describe the solution you'd like
The ability to specify the fork() options that are used when setting up the MikroOrmModule with scope = Scope.REQUEST.

This way you could specify { cloneEventManager: true } in the MikroOrmModule setup, and when the main event manager is forked for each request, the event subscribers attached to it will also be cloned (In the above example this would be the webhook functionality event subscriber). Afterwards, a request-scoped interceptor can kick-in and attach the request-scoped audit event subscriber to the cloned event manager.

The next request that comes in should clone from the main event manager, and therefore not include the old request-scoped audit event subscriber.

Describe alternatives you've considered
The only approach I can think of is to have a second token that resolves to a custom .fork() of the entity manager, and only inject that token when needing to access it - however, this means that I won't be able to use the built in entity repositories for injection either. I'd need to get the custom-token EntityManager and then get the repository from that instead. It also bypasses part of the NestJS module which is not ideal.

Any other options i've considered do not adequately handle the race condition of two concurrent http requests coming in at the same time.

Additional context
N/A