Remove QgsAbstractProperty and subclasses, and instead use a single
QgsProperty class which covers the use of QgsAbstractProperty
and its subclasses. This simplifies the API and avoids pointer
handling. QgsProperty is implicitly shared for memory efficiency
and inexpensive copies.
Instead of defining the suitable field types and values for
properties when registering them to a data defined button,
now properties are fully defined when the valid
property keys are defined.
To create a 2x2 raster block with one byte per pixel:
```
block = QgsRasterBlock(Qgis.Byte, 2, 2)
block.setData(b'\xaa\xbb\xcc\xdd')
```
To overwrite existing raster data at position 0,0 by the 2x2 block:
```
provider.setEditable(True)
provider.writeBlock(block, band, 0, 0)
provider.setEditable(False)
```
And overriding projection is only done if user has manually
chosen a different CRS from the list.
This means that templates and compositions in server can still
adapt to follow the project CRS, but if desired specific map
items (eg an overview map) can use the CRS override to always
show in a particular CRS.
This allows the CRS for map items to differ from the canvas/project
CRS. It also allows different map items to have different CRS,
eg an overview map can be set to a different CRS to the main map.
An unfortunate side effect of this change and the ongoing work
to separate compositions from canvas is that datum transforms
are no longer supported in composer. This cannot be fixed until
the datum transform store is rewritten to not depend on canvas
(ie, it's also broken for upcoming multi-canvas work)
Use relevant composer map item CRS instead of composition mapsetting's
CRS. For items directly linked to a map (eg scalebar, legend) we
use that map's CRS, for others (eg labels, html items) we use the
composition's reference map CRS.
(Note that the CRS cannot be set for a map, and is still currently
linked to the canvas CRS. Fixing that is a future TODO.)
