With the nick a mandatory argument; the only odd inherited gobject terminology
is "blurb", using the more descriptive "description" in the property
registration yields API assymetry.. but people manually working with
GParamSpecs should know what they are doing.

- introduce a GeglRandom structure instead of accessing the LUT each time
- make a larger cycle for the seed
- avoid segfault when a negative seed is given
- use g(u)int64 instead of long to avoid plaform-dependant behavior
- make opencl and operations follow that api change
- build the GeglRandom structure in the gegl-chant machinery when using
gegl_chant_seed
- make sure the pointer gegl_random_data is 32bits aligned when used with
CL_MEM_USE_HOST_PTR

Operations can now hold arbitrary string based key/value pairs, this
permits dynamically extending what is stored without needing to break
API/ABI, it also means we can encode things like gimp menu paths or
similar.

Made scale be a GeglMatrix2 instead of a gfloat, allowing to specify a more
correct sampling context. This is an API change, not many things are using the
GEGL so this should be fine. In GIMP there is one instance that needs updating
but it resides in #ifdef 0'd code so there should be no API conflict.