Add EditorTableModel

This will be used by ERED and the forthcoming SED
(SweepstakesEditorDialog) in order to allow the user to edit data.

----

WHY I HAVE BEEN INACTIVE
========================

First, I've been in the process of migrating to a new PC. I've had to
transfer all of my configuration, etc. to this new computer. Having this
project on Github simplified this somewhat, but it still took time to
transfer e.g. my Eclipse configuration.

Second, classes have started and I thus have less time in general.
ETM: Add doc note that stages shouldn't change column headers

The reason for the stage system is because of ERED. I'm planning on two
stages. The first allows the user to input event results. In preparing
for the second stage, the application generates sweepstakes points using
the event's specification. Then, in the second stage, these are exposed
to the user for editing.
We no longer have a four-arg ER constructor (doc update)
Add bare-bones EventResultsEditorTableModel

Longest class name in existence?

All the unimplemented methods will be implemented in due course.
Add Facet

Sensible parameter to pass into the (NYI) ERETM constructor. We can only
sensibly edit one facet at a time, so we need a "facet" parameter of
some sort.
Integrate ERETM with Facet
ERETM extends AbstractTableModel
ERETM formatting

I thought this would be taken care of.

*checks Eclipse settings*
ETM formatting
Formatting (Facet)

Newlining after every enum constant is an Eclipse setting I added for
when I'm working with more crazy enums (with constructors and class
bodies and all), but I guess it works here too.
Delete ERETM for now

I'm not really at a stage where I can add this. I think I need to add
another (abstract) class that handles things like ties, adding people to
the last place... Then, subclasses can add specific fields to this, as
well as actually converting this data to the desired format.
Add RankingEditorTableModel

--the aforementioned superclass. This will handle functionality such as
handling ties and adding rows at the end for ties for last place. For
example, it will create checkboxes in the first column for specifying
whether a row is a nonterminal member of a tie. (Additional rows will be
added/removed based on these checkboxes.)

I should probably ponder what I'll let this class handle and what I'll
let subclasses handle before writing this code. This might take anywhere
from a few nanoseconds to a few minutes. (to a few days...)

I also need to think about what happens if someone unchecks a box above
a row containing data (or several rows containing data) at the end of
the table. The logical behavior is to obliterate that data, since it's
no longer relevant (it corresponds to a tie that we're not tracking),
but we know that [l]users do stupid things all the time. (I'm talking to
you, `rm -rf .*`. Don't ever, EVER type that on a *nix system, by the
way, no matter your PWD.) Optimally, the system will store that data
somehow (maybe just hide the rows instead of deleting them) or present a
confirmation box before deleting the data.
Start working on RankingEditorTableModel

because why not?
Implement RETM constructor

Yes, my comments are a lot more verbose.
Document RETM constructor

getColumnCount will probably inherit documentation because of its
rudimentary function.
RETM: add retainPlaces
RETM: Declare data (init logic will be later)
RETM: Add invisible (initialization NYI)

Consider a four-way tie for last place. If an operator accidentally
checks the "End tie?" box for the top member of the tie, all of the
other rows will extend beyond retainPlaces and be removed. Having an
invisible list allows this data to be easily recovered (having to
confirm all tie edits would be too much of a hassle).

We will store the value of the boolean "end tie" field (so that an
accidentally deleted tie can be reconstructed in one click). If we reach
the end of the stack and the last popped member has this field set to
false, a new row should be inserted at the end with default values.
Add RETM.updateForNewRowCount, excluding event firing

This will form the backbone of our logic and will be executed from other
methods. Since event firing doesn't have to do with the logic of adding
or removing rows, I'll be implementing it later (probably in the next
commit).

My unofficial goal for the RETM class is to handle all of the
functionality itself, with subclasses (e.g. those dedicated to editing
EventResults or sweeps) only specifying the contents and doing any
specific logic (e.g. a school autocomplete, time permitting).
RETM.updateForNewRowCount: Add event firing