feat(engine|rest): introduce typed variable API

Introduce typed variable API in process engine and REST API.
Allows specifying the typed and additional properties of variable
values:

  // create a variable of type "string" and value "null"
  execution.setVariable("foo", stringValue(null));

  // add additional metadata to object value
  execution.setVariable("customer",
    objectValue(customer).serializationDataFormat("application/json"))

  etc...

Motivation:
==========

Before, the process engine provides an "untyped" API for working with
variables.This leads to some subtle limitations:

Null values:
------------

1) It is impossible to initialize a variable with "null" and declare
   a type for it:

  execution.setVariable("myVar", null);

=> type of variable cannot be detected by process engine and will be
"null".

2) It is impossible to get the type of a variable which has variable
   null. I cannot

  Object object = execution.getVariable("myVar");
  object.getClass() // < will throw NPE if object is null

All of this is OK as long as I am "only" writing Java Applications in
which I know the types of my variables everywhere. However, it causes
problems when
- developing a clean REST API
- developing "Generic" applications such as Cockpit or Tasklist
- crossing the language barrier and use Java Script (for instance when
  developing task forms)

Additional Metadata:
--------------------------

1) It is impossible to attach and retrieve additional metadata to
   values. For instance, when working with XML data, you cannot
   specify additional metadata in the variable value such as
   Namespace / Schema information.  While this can be to a certain
   extend embedded in the value itself when working with XML this is
   not trivially possible when working with other dataformats such
   as JSON or CSV...

2) Additional Metadata is also relevant when working with serialized
   Java Objects. There the requirement is to be able to get and set
   the type of the java object even if the object itself is

  a) null
  b) not deserialized (this is required in situations where we cannot
     deserialize the java objects due to classloader restrictions)
  c) specify the value in a different format such as JSON or XML

3) Formulating restrictions (read-only, type-change allowed ...)

related to #CAM-2903