direct QPainter argument
This will make use of other rendering code within layout items
much easier - since symbology/text renderer/diagrams/etc all
require QgsRenderContexts for use, it makes sense for
layout item rendering to also use this approach.
This also avoids lots of duplicate code which was scattered
throughout different composer item types to manually handle
creation of QgsRenderContexts when required.
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.
auto create actions for adding new items of the newly registered type
This avoids hard-coding in available item types into layout UI classes,
and allows designers to handle plugin-supplied item types
These classes are used for storing measurements for a layout
(QgsLayoutMeasurement), sizes for a layout (QgsLayoutSize)
and points in a layout (QgsLayoutPoint)
They support storing a measurement unit alongside a measurement
length/size. A new class QgsLayoutMeasurementConverter handles
conversion between different units, including converting to and
from pixels via a specified DPI property.
