feat: use getRepository instead of createEntityManager

[tillkolter]

Hi,
first of all, thank you for porting the original repository to support later TypeORM versions.

My PR is a rather short one and I frankly don't know if my intended solution is too niche for the bigger picture on how general this library needs to be. But maybe I hope I can win you over. I have tapped into TypeORM only for about a week, so my judgement call might not well educated.

I am currently improving the test suite for a NodeJS project, trying to make the integration-testing developer experience as close to batteries included ecosystem like Python Django or Ruby on Rails, which was the reason why I came across your predecessor's library to support a factory_girl like pattern.

Besides adding a factory pattern to create test entities, I had also integrated this library to support isolating test cases inside their own transactions which can be rolled back after execution. The problem is, that now the typeorm-factory entities are created in different transaction contexts, because each Factory.create(...) creates a new EntityManager instance.

The typeorm-transactional works by patching the DataSource.manager and EntityManager.prototype.getRepository (in contrast to createEntityManager). After some consideration where to fix my issue, I came to the conclusion that I'd rather fix this issue on the factory side, because the factories operate on a higher level of the stack and there are probably good reasons not to patch createEntityManager or even the underlying EntityManagerFactory to keep special use cases intact, where the manager creation is needed to for custom SQL queries.

[inossidabile]

@tillkolter I think the better approach would be to do this.dataSource.manager which is more compatible to the way it works currently. Using repos is an unnecessary wrapper. We could do a protected method getEntityManager() on the level of Factory and default to current implementation but allowing us to override it and keep general transaction.

Breaking out of current transaction still makes sense for some cases and changing it by default is not backward compatible. Let me quickly draft another PR with alternative implementation.