Give the raster the class its own type carries

[estebanzimanyi]

The object model holds Raster in the Value hierarchy beside Raquet, with the prefix raster and
a null temptype, MEOS registering a raster in no enum while every raster function takes one
first: raster_copy, raster_mem_size, raster_width, raster_clip and the other raster functions
are methods of it, copy, memSize and width among them, and its instances are a Raster *.

The floor of .github/workflows/pytest.yml rises to 537, the suite collecting the Raster test of
the object model.

Witness: against MEOS-API master 4baf117 over MobilityDB master 4eef012a9f raster_copy,
raster_mem_size and the 35 other raster functions are unclassified, no-prefix-match, so a
binding generating from objectModel.classes declares them as free functions; against this
branch they are methods of the class Raster, its cType Raster.

Measured over MobilityDB master 4eef012a9f with an all-families libmeos, run.py on upstream
4baf117 and on this branch with the same installed headers: the two catalogs differ in the
object model alone, every key of every function, structure and class of typeEncodings being
identical; it classifies 37 more functions, all to Raster, leaving 3129 unclassified. The
suite collects 537 tests, all passing, none skipped. JMEOS main e8c65dc4 generates
byte-identical GeneratedFunctions and object layer, and identical Spark, Spark SQL and Flink
SQL surfaces, from both catalogs; its Flink and Kafka facades carry the same 5206 methods, the
37 raster functions in MeosOpsRaster beside the 5 left in MeosOpsFreeRaster.

Why: a binding types a raster method and the value it answers from the object model, which
holds a class for every value MEOS passes by reference.