fix(sql/drop): adjust drop constraint statements

related to CAM-2189
feat(caseExecutionQuery): query after disabled case executions

related to CAM-2192
test(ui-test/admin): improve admin ui test suite
chore(webapps): improve accessibility for ui tests
fix(engine): fix camunda:inputOutput parser to support nested lists

related to #CAM-2399
feat(engine/scripttask): add ability to use external script resource

- script source can now be returned by an expression
- script source can now be loaded from an external script
- external scritps can be found in the deployment or the classpath
- the path for the external script can be returned by an expression

related to #CAM-2357
chore(engine): close inputStream in resource util

related to #CAM-2357
feat(userOperation/case): query by caseExecutions after operationLogs

This commit adds new columns to ACT_HI_OP_LOG:

- CASE_DEF_ID_
- CASE_INST_ID_
- CASE_EXECUTION_ID_

Furthermore the UserOperationLogQuery has been extended by new query parameters:

- caseDefinitionId()
- caseInstanceId()
- caseExecutionId()

related to CAM-2189
feat(userOpLog/REST): extend UserOperationLogQuery

related to CAM-2189
refactor(case/core): divide & conquer responsibilities

This commit refactors the way how a case instance will be executed.
Therefore the responsibilities have been divided into three parts:

- AtomicOperation:
  * controls the lifecycle of a case execution
  * set the state of a case execution
  * if necessary removes a case execution and/or notifies the parent that
    the state of a child case execution has changed

- ActivityBehavior:
  Contains the rules and behavior for stage, task, milestone or event
  listener instances (associated with a case execution) to be executed
  in a specific transition, e.g.
  * checks that a transition is allowed
  * if a HumanTask gets active, a UserTask will be created
  * if a Stage gets active, for each defined child activities a new case
    execution will be created

- CaseExecution:
  A case execution holds the state, different necessary references and
  delegates different calls to the right AtomicOperation, e.g.
  * if CaseExecution#manualStart() will be called, then the implementation
    delegates to the AtomicOperation which is responsible for the
    transition "manualStart"
  * etc.

Furthermore the whole lifecycle (except the FAILED state) has been
implemented in the core part of the engine. For example:

In case of a stage or a task instance the following transitions have been
implemented:

- create
- enable
- disable
- re-enable
- start
- manualStart
- terminate
- exit
- suspend
- resume
- parentSuspend
- parentResume
- complete

In case of a event listener or milestone the following transitions haven
been implemented:

- create
- suspend
- resume
- terminate
- parentTerminate
- occur

In case of a case instance the following transitions have been
implemented:

- create
- complete
- suspend
- terminate
- re-activate
- close

Note: Not all transitions are not exposed via the public Java API.

However, the following properties will also be evaluated:

- requiredRule
- manualActivation
- autoComplete
- isBlocking

related to CAM-2189, CAM-2192, CAM-2194, CAM-2190, CAM-2191, CAM-2195,
CAM-2197, CAM-2196, CAM-2193, CAM-2198
feat(completion): complete a HumanTask, Stage or CaseInstance

This commit adds the feature to complete an active HumanTask (Task), an
active stage or an active case instance.

This can be done by using the CaseService, e.g.

  caseService
    .withCaseExecution("aCaseExecutionId")
    .complete()

In case of a HumanTask which is associated with the given case execution
the created UserTask will be completed (Note: using the TaskService to
complete a UserTask will notify the CaseExecution to complete too, so that
completion works in both direction).

In Case of a Stage (and a CaseInstance) the completion can only be
performed, when the following criterias are fulfilled:

- there are no active children
- all required children (requiredRule evaluates to true) are {Disabled,
  Terminated, Completed, FAILED}

If a case execution has been completed the parent of the case execution
will be notified, that the state of the child execution has been changed.
According to the completion the parent case execution checks whether it is
also able to complete, and if the parent case execution is able to complete,
the parent case execution will be completed too. So, the completion will
always be propagated to upwards to the parent stage instance.

Furthermore it is possible to query after completed case instance:

  caseService
    .createCaseInstanceQuery()
    .completed()
    .list()

related to CAM-2190, CAM-2191, CAM-2195
feat(complete/REST): expose completion via REST Api

related to CAM-2190, CAM-2191, CAM-2195
feat(engine): correlate a message to multiple executions in one go

This commit adds the possibility to correlate a message to multiple
executions in one go. This can be done by using the following Java Api
method:

  runtimeService
    .createMessageCorrelation("aMessageName")
    .correlateAll();

This operation doesn't have the restriction of correlate() that not more
than one correlation matches are allowed.

related to CAM-2006
fix(cycle-it): ignore BPMNLabelStyle ids
feat(REST): correlate message to multiple executions in one go

related to CAM-2006
fix(engine-rest): use new mock for message correlation builder

related to CAM-2006
fix(qa): increase perm gen space cause of errors
feat(close): close a completed Case Instance

This commit adds the feature to close a completed case instance, so that
no further work or modifications are allowed for the associated case
instance (ie. the case instance has been removed from the runtime and is
not available anymore - note: at the moment no history is written for case
instances).

A case instance can be closed as follows:

  caseService
    .withCaseExecution("aCaseInstanceId")
    .close();

related to CAM-2197
feat(close/REST): expose closing a case instance via REST API

related to CAM-2197
improve(grunt): use the app.port variable instead of hardcoded 8080