Add framework to allow test-specific assertions on HTTP response.

[paulmillar]

Motivation:

Individual tests may have certain expectations on how IDS responds to
HTTP requests.

Some interactions supported by TestingClient exercise IDS requests
that return content; for example, getData. For these interactions,
TestingClient returns the content from IDS and not the HTTP response.
This makes it impossible for a test to assert that, for these
interactions, the HTTP response from IDS matches the test's
expectations.

Modification:

Update TestingClient to allow the test to include one or more
assertions on the HTTP response. The support following the builder
pattern.

The assertions are provided by the test as Consumer objects that accept
an HttpResponse object, with lambdas providing an easy to build such
objects. Some static methods are included that provide common
assertions, to keep code readable and DRY.

The Apache client is customised to include a response interceptor,
through which the assertions are made.

The existing code that checks the combined Content-Length (if present)
and Transfer-Encoding headers (if present) is valid is refactored to
take advantage of this framework. This check now applies uniformly to
all HTTP responses from IDS.

Some other, existing tests are updated to take advantage of the new
framework.

Further refactoring is possible; for example, to make the check on the
response's status code more explicit. Such a refactoring would reduce
the complexity of the TestingClient interaction methods by reducing
the parameter count.

Result:

It is now possible to write tests that make test-specific assertions on
the HTTP response from IDS for interactions where IDS returns content.

[paulmillar]

I'm closing this pull request as it isn't clear what is the best strategy for processing the proposed changes. This is something that could be discussed in issue #155.