in the qml port I incorrectly registered the cpp types as singletons,
but from a registration POV (which is application-wide) they aren't
singleton. they are bound to the context of the plugin instance that
created them. alas, this is a bit awkward to present because none of the
classes can deal with post-ctor initialization (that is: qml would ctor
the objects and then configure them through the properties) so we can't
use them through QML directly. we could construct them per-engine with
the qmlRegisterSingletonType callback system, but that's a bit tricky
because Model, UserManager and ShareContext are tightly related, so we'd
have to do extra fiddeling to get them to link up.

instead simply expose these three as properties on the plugin and set
the plugin as contextproperty. longer-term it may be worthwhile to
change the three classes to support qml-style property construction so
we can construct them from QML as that would then also resolve some
asyncness concerns I had about the fact that the ctors are doing data
processing (even though it is very lightweight data).

this also makes the root widget of the page a unique_ptr. because of the
child ordering here the widget is actually a sibling of the plugin
instance so it can and will get deleted after the plugin which results
in bogus warnings as the context property (the plugin) gets destroyed
and all bindings get reevaluated against the now null property

BUG: 425591
FIXED-IN: 20.12