Updated git submodules

Updated git submodules

Project: so master d2e69c0d689596033a9c35aa98d37a44e2cc88cb

WorkflowResponse json issues

This commit adds some robustness to the interface between the
API-H and BPMN, specifically, in how the response is handled.

I don't have proof, but there appears to be some randomness to
the json provider behavior when used with the jax-rs. Sometimes,
the serializer is adding the root element, and sometimes it
is not.  Maybe there's something wrong with the configuration.
Maybe we have competing json providers.  I couldn't pin this
down.

I'm almost certain it is the presence of the root element in
the content that causes the API-H code to fail parsing of the
BPMN response.  This doesn't kill the request, as you might
expect, but rather, the API-H passes the BPMN response through
to the client (VID, or policy, or whatever).

The original problem (SO-586) was "fixed" by "removing the
wrapper".  This "wrapper" is a needed feature of the interface
between BPMN and the API-H.  We shouldn't have removed it.
The fact that the "fix" appeared to work is due to the
behavior I described in the previous paragraph.  The API-H
chokes on the message, and it passes it through unchanged.
Not really what we want.

So, I don't know why the jackson/json behavior is flaky and
different now, but I can (and did) modify the API-H so it can
parse a json message whether or not it has a root element.

Note that WorkflowResponse.java (in BPMN) and CamundaResponse.java
(in the API-H) are basically the same bean representing the
message format.  Seems less than ideal to have two different
classes.

Also note that I changed the name of the "response" attribute
of the WorkflowResponse and CamundaResponse classes to "content".
Got tired of seeing this nonsense everywhere in the code:
	response.getResponse()

Change-Id: Icaf70f8457de99e493cf882170fe778c620308c9
Issue-ID: SO-586
Issue-ID: SO-618
Signed-off-by: Rob Daugherty <rd472p@att.com>