docs(IncidentManager): rename parameter to reflect its content

The name jobQuery is confusing when using this manager, because it
actually expects an IncidentQuery. This is most likely a copy and paste
issue.
Merge pull request #114 from falko/rename-incident-manager-parameter

docs(IncidentManager): rename parameter to reflect its content
chore(engine): remove irrelevant deployment name

related to #CAM-2758
chore(maintain): fix typos, code style
chore(index): add index on task assignee to improve performance

related to #CAM-2130
chore(engine): remove duplicate field
feat(engine): add HistoricCaseActivityInstance to history

related to #CAM-2841
feat(rest): add historic case instance rest service

related to #CAM-2840
test(engine): add failing test case for execution listeners

related to CAM-2937
fix(engine): prevent job retries to become negative

related to #CAM-2884
chore(rest): add states to HistoricCaseInstanceDto

related to #CAM-2840
feat(rest): add historic case activity instance rest service

related to #CAM-2842
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
test(engine): JaxB Object Serialization

- add testcases for JAXB Object Serialization

related to #CAM-2885
fix(engine): synchronization & async inclusive gateway

make sure async inclusive gateway synchronizes properly

related to #CAM-2942
feat(rest): embed case definition in HAL task and task list

related to #CAM-2940
fix(rest): fix failing test cases of variable rewrite

related to #CAM-2903
test(engine-rest): variable requests without object deserialization

related to CAM-2889
test(engine): add failing testcase for case insensitive task name order

related to #CAM-2827
feat(engine): add case insensitive task name ordering

related to #CAM-2827