user_manager.py: Support alternative managers passed to init_app()

[dsoprea]

Currently, we can call init_pp() and then overwrite the managers afterward, but this a) requires us to interfere with the semantics of the UserManager object in a way that might affect upgradeability (or, conversely, your ability to make changes while avoiding those issues), and b) can't avoid side-effects related to those initial instances. For example, I might create a custom DbManager and assign it into the UM object but other references to the original UM object remain elsewhere. So, part of the flow will be using the old instance and part of the flow will be using the new instance.

This is the point of providing accessors but leaving the members/attributes of the class to be exclusively established by the internal logic of the class. I, as a consumer of the class/project, should have a path forward in customizing what I need to via parameters, and you, as maintainer of the class/project, should have a path forward to be able to make changes to the shape/flow of the project without being prevented from doing so because I've interfered in a scope that I shouldn't have had to.

TLDR: This is a minor change to allow the main managers to be overridden via constructor. I attempted to run the tests but it failed with the same issue that's currently plaguing the CI tests.

[ECrosland]

If Flask-User is still maintained, I'd like to see it possible to pass the email adapter to init_app also.

I am trying to move from Flask-Mail to Flask-Mailman, since the former is no longer maintained, and I've got my own implementation of Flask-User's email adapter interface that uses Flask-Mailman. However, since an instance of the default SMTPEmailAdapter is created in init_app, I am not able to uninstall Flask-Mail without Flask-User complaining about its absence.