Remove serialver from Slide interface [EXPLANATION OF COMMITS TO FOLLOW]

My intent with the implement-slides branch is to write a SlideList
interface and subinterfaces. Each subinterface will carry a different
type of metadata. This will provide richer data for the server to
retrieve, since I'm aiming for the server to constantly check state with
the client. Most likely, SlideList will in turn implement List.

Then, I will implement each of my subinterfaces. I'll probably also
write a WelcomeSlideList class or similar, intended for the first slide
in the projection.

I will keep SlideFactory in order to allow me to generate multiple
slides for one Event. I'll probably also change the network protocol to
handle Map<String, SlideList> instead of Map<String, Slide[]>.

I literally thought this up while amending this commit message. Rubber
duck software design is awesome.
Add skeletal SlideList
SlideFactory.generate now returns SlideList
Map<String, Slide[]> -> Map<String, SlideList>
Delete SlideFactory after all

Its functionality will be fulfilled by the constructors of the SlideList
subinterface implementations.
Obliterate a lingering Map<String, Slide[]> in an exception message
Add EventResultsSlideList
Add SweepstakesSlideList
Add EventResults.getEvent

How the heck have I not already done this?
Add EventResults copy constructor
Add a skeleton DefaultEventResultsSlideList (impl all interface methods)
Add fonts to DefaultEventResultsSlideList
Make DefaultEventResultsSlideList fields private

I always forget private when adding fields. Probably because you don't
add access modifiers to local variables in methods.

GRRRR
Change the Slide interface to use Graphics2D
Revert "Change the Slide interface to use Graphics2D"

This reverts commit 7fa7215fcff442c24a7425375ea66b6af8db93b1.
Change DefaultEventResultsSlideList constr sig: Graphics2D -> Graphics
Create a skeletal BuildableStackedSlide
Add Graphics parameter to BuildableStackedSlide constructor

No sanity checks on whether we're drawing with the same constructor that
we pass in here; TODO.
Add the Chunks to BuildableStackedSlide
BuildableStackedSlide: Add the buffers for the [COMMIT SYSTEM]

THE COMMIT SYSTEM
=================

1. User adds chunks using public methods.
2. Each chunk add method tells the user whether the add succeeded (i.e.
whether room is left on the slide).
3. Periodically, the user "commits" the added chunks. This moves them
into a list where they will actually be drawn.
4. If the user has partially added a section that they wish to remove,
and has not committed it yet, they can "revert" the chunks that they've
added, which clears the list of uncommitted chunks.

I might add a dual-layered commit system with three buffers, where you
can commit and revert, as well as superCommit and superRevert (those
commit what has already been committed or revert what has already been
committed).