New class to hold boundary data

Some of the GIS queries return a bounds, which comprises two points that
represent a diagonal on a rectangle.  Rather than try to work out the
width and height of an appropriate Java Rectangle2D.Double, I decided to
create a data container class instead to hold four double values: xMax,
yMax, xMin, yMin.
Proxy class for BoundaryRectangle

The sole purpose of this class is to package BoundaryRectangle data in a
way that is amenable to streaming as JSON data.  The class looks
slightly redundant alongside BoundaryRectangle but I've tried to make it
a policy to isolate all classes for web services in the
rifServices.restfulWebServices package.  I'm trying to keep the business
classes free of annotations or fields that would service a JSON output
that is needed by a particular type of front-end client.
Modified method signatures

Modified methods in the study result retrieval API so that some methods
(1) return a BoundaryRectangle object instead of a Java
Rectangle2D.Double object and (2) make use of a
StudyResultRetrievalContext parameter instead of separate parameters for
Geography, GeoLevelSelect and DiseaseMappingStudy
Added a printErrors method
Added messages for study result retrieval service

Added message strings for sqlResultsQueryManager and for general
auditing messages when the methods of a RIFStudyResultRetrievalAPI-based
service are called.
Added a print errors method
Makes use of BoundaryRectangleProxy

Methods for returning bounds now return a serialised instance of
BoundaryRectangleProxy that can help generate JSON output
Tests retrieval service methods related to bounds

Is the test class for methods in RIFStudyResultAPI that return bounds
Overhaul of automated tests

Initially, the test cases which exercised the service APIs were grouped
together by themes corresponding to business classes (eg:
"TestAgeGenderYearServiceFeatures".

Now, each API method has its own test suite.  The test cases are
generally designed to fail due to a minimum number of assert statements.
The sheer number of test cases which have been created warranted a
different approach to documentation

Now most of the meaning of a test case can be interpreted based on the
naming convention used for method names. Here are conventions:

[method name]_COMMON[1...n]: Common case test cases.  They use typical
data and obtain a typical result.

[method name]_UNCOMMON[1..n]: uncommon test case scenarios.  For
example, it would be unusual yet valid to fetch a block of calculated
results where the start and end indices are the same.

[method name]_NULL[1...n]: check for a null method parameter value.  n
will almost always correspond to the nth parameter in the method
[method name]_EMPTY[1...n]: checks whether a method parameter is (1) a
String with a value of the empty string "" or (2) a business class which
has a field that is blank or has another object with a blank field. n
refers to the nth parameter.

[method name]_NONEXISTENT[1...n]: uses a non-existent value for a
business object that is passed to the API method
[method name]_MALICIOUS[1...n]: attempts to detect a malicious String
field value.  The detection is recursive within a business object that
may in turn have other business objects.  n is the nth parameter.
Introducing StudySummary class

We needed a more convenient way to return part of a study rather than
all of it.  The fields needed were: (1) a study ID and optional
description fields.
Modified health code sample data

Modified sample values of Health Codes to reflect the contents of the
XML document containing sample ICD10 codes.
Added more test suites for more API methods
Reordered the import statements

Trying to keep order of import statements consistent:
(1) list imports of rifService.*.* packages
(2) list imports or java-related packages
Removed old test suite
Added more factory methods for test data
Changed reference from job to study submission
Add methods to check for non-existent items