Majro design change in reporting but affects framework as well.  See details.

In the previous design we argued for keeping the object that collects
timings (called Timings) seperate from reporting.  However, that
approach led to duplication, hard-to-name classes (there seem to be two
classes that could go with the same name!), and a big TestResult class
— 36 lines.

When I re-looked at the design, an idea flashed — why not use the
Timings object to directly collect the information needed for
reporting.  This was done in TimingsTests.run() where we invoke
Timings.run(method, each).  This was a big breakthrough and it
eventually led to this design.  Timings is now renamed Report.

The other big issue that has plagued this prject was how to seperate
ordering and formatting.  In this design, we use composition.
TestResultsReport has code for ordering, and formatting is done by
sub-classes of TestResult.  TestResultReport uses an an enum to
instatitate the right TestResult and then stores it in a list.  When
print() is invoked, this list is looped through.  So the outer class is
for ordering and it holds references to objects that format.

The design results in small objects with clear names and hardly any
duplication.