Many improvements to source.

I've made a lot of progress lately. Some of these involve the creation
of an internal date API to make time manipulation far easier, the
automatic conversion of integers into Strings whenever possible,
timezone matching with Java's system to support DST, a built-in date
formatting system with support for ordinals and optional years,
customisable page sizes for users, and automatic aggregation of results
based on an aggregation mode. Much more is on the way soon.

Internal date API: I'm so sick of Java's date system, so I've decided
to make a barebones API that wraps around the Calendar classes
available in Java. This will make manipulation so much easier. I am
working on rewriting the TimeLexer class to be optimised for the new
system.

Automatic String conversion: Whenever using the read(String message,
String... params) method from a MessageAssist instance, Tracker will
automatically check if an object is an Integer (and try to find the
appropriate number in the message keys). If it can't, Tracker will try
to convert the number into thousands (i.e. 1000 -> 1,000). Also, I can
now use a string with the section (§) key to make Tracker read it from
the message file.

Timezone matching: Timezones can now match their appropriate Java
counterpart so Tracker can support DST.

Built-in date formatting: I felt this was necessary because of the lack
of ordinal support for SimpleDateFormat. This class essentially does
the same thing as SimpleDateFormat does, but it also supports ordinal
numbers with 'o' right after a number.

Customisable page sizes: Pretty self-explanatory - a user can now
change how many results should appear on a page.

Automatic aggregation: My previous method of aggregation was slow and
it even *looked* processor-intensive. Now, we will just compare changes
whilst constructing an iterator. There are two modes of aggregation -
LOOKUP and TELEPORT. LOOKUP groups similar results together, whilst
TELEPORT groups nearby results together. Tracker will use NONE (no
aggregation) if a user has the option disabled (or we're using the
iterator() call for changes)

What is left?
  - Listeners / Heuristics
  - Tool behaviour
  - Commands
  - SQL retreival and insertion
  - Change executors and reversals
  - WorldEdit support
  - Testing

I'd say there remain about 2k-3k lines of code until we finish (and it
already has 7739 lines!).