Changed service registrations from Transient to Singleton.

[paulomorgado]

What issue does this PR address?

Addresses #51

[josephdecock]

Thanks!

[josephdecock]

Note: Need to document this as a breaking change in the release notes (hence the tag), because customizations that have scoped dependencies will have to be updated.

[brockallen]

I'm happy to revisit this PR as a whole if customizations are more difficult due to the assumptions imposed by things being registered as singletons.

[josephdecock]

I am going to revert this change because of the potential to cause breaking changes for users. Any customization that is injecting a scoped dependency would be required to have an update, and we've decided that that is too much of a breaking change for the potential reduction in memory allocation. When this first came up in #51, I wish I would have highlighted from the start that our driving design goal here is to be extremely flexible and customizable, and one way that we facilitate that is by making our services scoped so that customizations can use scoped dependencies easily.

If anyone is experiencing performance problems or memory pressure coming from this code, we do want to hear about it, and we could potentially revisit this (especially if we hear of more practical performance issues). But for now, we need to pull this out. I believe it is technically possible to re-register the dependencies as singletons to override their lifetime as well (admittedly, a bit of a PITA, but a way to get this behavior if you really need it nonetheless).

[brockallen]

Also, anyone where the memory issues are particularly important can always re-register things as singletons, yes?

[josephdecock]

Yes, that should be possible.