Instead of relying on forward declared c++ classes from
gui in QgsLayoutItemRegistry, instead create a
QgsLayoutItemGuiRegistry which handles registration
of all the GUI specific behavior relating to layout items.
Remove all GUI related code from QgsLayoutItemRegistry.
This creates a cleaner split between core/gui code, and
given that there'll be a lot of gui specific behavior
which needs to be handled by a registry it makes sense
to keep this isolated in gui.
It also plays nicer with the sip bindings, which can't
handle forward declared gui classes in core.
c++ QgsLayoutItem metadata classes can directly register
a function which creates a QgsLayoutViewRubberBand for the item
subclass.
Python code cannot utilise this shortcut (due to inaccessibility
of forward declared gui classes from core Python classes), so
there's a separate gui registry utility class added for registering
prototypes for rubber bands for already registered item types.
Copy the same model as QgsMapCanvas uses, with separate
classes for individual interaction tools instead of keeping
all the logic in the QGraphicsView subclass (as is done
with composer)
The button can now be used in two different modes. The default behavior
is to include all settings used for configuring
QgsTextFormat/QgsTextRenderer classes. A cut down mode (without settings
for color/buffer/drop shadow/etc) is also available when the resultant
font is to be used only in a QFont object.
A standard widget for configuring text format properties for use
with QgsTextRenderer/QgsTextFormat.
It's modelled heavily off QgsColorButton, and supports lots of nice
things like dragging formats between buttons, copying and pasting
format settings, dropping colors from color buttons, dragging colors
from font buttons to color buttons, directly setting font size
and opacity/color without having to open a dialog.
Previously this was only enabled for optional arguments (i.e.
those with default values). Enabling them for all arguments
allows for more readable PyQGIS code, and there seems no
downside given that we already have this support partly enabled.
The consequence of this change is that when 3.0 API is frozen
the freeze must also include the naming of function arguments,
since that's effectively now part of public API.
