According to my calculations, multiSort is stable

Since we add indices to the Lists in numeric order, this should be
stable. If not, my unit test (which I am writing at this moment) should
not be too shy to point it out.
Fix an NPE related with uninitialized elements of a 2-D array

The subarrays of a 2-D array are initialized to null, which gave me an
NPE in my unit test suite (soon to be committed). To fix this, I used
more reflection (YAY!) to instantiate a subarray in each index of ret.
This seemed to work fine.
Add ArrayUtilsTest

Other than an NPE (just fixed), this has safely reassured me that my
multi-sort code is flawless.

You see, Real Programmers don't write buggy code.
</sarcasm>
Wipe SweepstakesAssignment.CUSTOM off the map [REASON INSIDE]

WHY DID I REMOVE CUSTOM?
========================

Originally, my plan for SweepstakesAssignment was for its assignments to
be "set in stone." There would be no way to change what you got from the
assignPoints method. To rectify this, I intended for sweepstakes points
to be user-editable if given a special configuration; this ended up
being SweepstakesAssignment.CUSTOM ("c" in the event config).

Later, I realized that it would probably be better if all sweeps results
were modifiable by the user before publication. The
SweepstakesAssignment would serve as a sensible default that the user
could use if it produced correct results. If not, the user could make
edits, if needed. (This also will serve to help mitigate the effect of
bugs in my logic, though I like to think that my unit tests will have
caught all of those.)

My intent is to add methods to Sweepstakes to make the sweeps totals
editable. Totals will be editable per competitor and passed in as if by
the results of assignPoints: as a "condensed" int[][]. I will also need
to ensure that DERSL's addTie methods doesn't assume that all
competitors in a tie have the same amount of points; this will require a
signature change for those methods.
DERSL: addTie methods take a map of sweeps instead of one fraction

To facilitate arbitrarily user-editable sweeps points, we must allow
users to specify sweeps points independently for all competitors, even
if two competitors are tied. (I have actually seen this; at one
competition, two schools were tied for first place in an event, and one
school received two more points than the second.)

We pass sweeps directly from the addList methods to the addTie methods;
the addTie methods will only use those records that correspond to
honoree names in the tie, so superfluous keys don't matter.