Major design change in Reporting -- see details.

So far, we have been trying to seperate layout from formatting in the
design of objects involved in reporting.

However, one of the main problems with the designs has been the long
parameter lists in method calls.  The parameters — size, method name,
timing — are passed to Report and other objects so that they can be
formatted.  These parameter lists are a SMELL, indicating that data and
behaviour are not grouped in the same object.

In this design, we adress this issue.  Now the object TestResultExport
has all the data — size, method name, timing — and the code to format
is also in the same object.

To accomplish this design, we had a major insight — which came when we
looked at the package dependencies.  The domain objects and the
reporting objects were interdependent, and there was no way to seperate
them into different packages.  This was a BAD SMELL.

To solve this issue, we used the collecting parameter Timings in the
domain code to just collect the test results.  We removed from it any
reporting code or dependencies on Reporting objects.

Next, we created Report and other objects that did the reporting.
These objects exported the data out of Timings to do the reporting.

Another headache with previous designs was building the report header.
We solved this problem with a new object called Title.  Using
TestGroup, Title avoids duplication to build the report header.

Here are the details.
1. Timings now doesn’t depend on Reporting objects;
2. Reporting takes care of layout;
3. All core data for reporting is in TestResultExport;
4. TextResultExport now does the formatting;
5. Format enum creates the type of TextResultExport;
6. Title now takes care of building the report header.