Consider allowing initialisation of many themes

In 5.15, importing QtQuick.Controls will result in the theme for the current style being loaded:

https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/imports/controls/qtquickcontrols2plugin.cpp?h=5.15#n263

It loaded the plugin(s) specified by the qmldir of the current style, and then called initializeTheme(theme) on it:

https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/imports/controls/qtquickcontrols2plugin.cpp?h=5.15#n120

The documentation says:

The fallback style must be the name of one of the built-in Qt Quick Controls styles, e.g. "Material".

If the user sets "MyStyle" as the style, and "Material" as the fallback, no QQuickTheme will be initialised at all, since QQuickStylePlugin and QQuickTheme are not public, so the user has no official(ly documented) way of implementing them. Users can still affect how the controls they implement look, just not via QQuickTheme. The Material style will still be used for the controls that the user's custom style doesn't implement, and because of QQuickMaterialStyle::initGlobals(), those controls will have the correct colours, but anything set by QQuickMaterialTheme will not be used.

When we introduce a public API for styling, QQuickTheme and QQuickStylePlugin will be available to users and so they can implement their own themes that will be used. However, I see two issues:

1. If we want the Material and Universal styles to make use of the palette API (like Default, Fusion and Imagine do), they'll need to stop using their attached API for colours. This will render initGlobals() useless, and so then both fonts and colours from those themes will not take effect. However, I don't see how this (making e.g. Material use the palette API) can be achieved currently, so this is probably not worth worrying about.
2. Fonts from fallback themes will still not be used. I don't know if this was intentional or not: maybe the idea was that the current style gets to choose the font and that it should apply to every control scope. Edit: not sure how I came to this conclusion; would need to double-check this because e.g. QQuickMaterialTheme::initialize does set fonts.

There are potentially three styles used in one application: the current style, the fallback style, and the Basic style, which is used as an implicit/final fallback if another style is set as the fallback.
I'm wondering if we can initialise all three themes, starting backwards:

• QQuickDefaultTheme::initialize() is called
• QQuickMaterialTheme::initialize() is called
• MyStyleTheme::initialize() is called

That way, each theme can set its fonts and colours, and the current theme always wins if more than one theme sets a font or palette for a given scope.

This would change the concept of a fallback style from one where it merely implements missing controls to one where it also affects any fonts, palettes, etc. that weren't specified in the current style.