Create DisplayPanel.initStreams() [NETWORK-RELIABILITY SCHEME HERE]

This is the reason I started the network-reliability branch--to sort out
the network programming of this app after I've given it some thought.
Today, I came up with a scheme for how to do the network programming on
this app right (described below). To do this, I need to revamp the inner
working of this app and delegate more to DisplayPanel. My eventual plan
is to give DisplayPanel a main function and obliterate the poor excuse
for a class that is Display.

The Master Plan
===============

Essentially, whenever the server sends a message that requests a reply,
it sets a timeout. (Most non-reply messages will soon be followed by
reply messages, and the server will essentially make absolutely no
assumptions about the client's state. In fact, this might be a good
excuse to make the display the server that can communicate with multiple
clients...but that would be feature creep, probably an issue for a
future release.) If the client doesn't reply, or the server hits EOF,
the server instantly closes the connection and pops up a
WaitForConnectionFrame. (There's also a Close Connection option with
confirmation in the DisplayPanel's control, which is probably going to
be stdout.) If the client detects a connection closure, it does the same
with a ConnectionDetailsFrame AND KEEPS DISPLAYING THE PROJECTION AS IF
NOTHING HAPPENED. The client MUST be able to operate autonomously and
continue displaying the data it already has. Note that neither end sends
Message.POISON; this would tell the client to close the slideshow.

Now, the server backs up all commands sent to the client. If the server
or client happens to crash and restart, there's a backup stored on the
server computer.
DisplayPanel's constructor now takes a Socket, not OOS/OIS

Next step in Ye Grande Networke Programminge Refactore.
Add field DisplayPanel.sock
Add DisplayPanel.commsActive field and associated getter
Add Javadoc note about data persistence to DisplayPanel

Unless restarted, the client NEVER loses data. Added a Javadoc note
about this.
Add note to extend Slide

Yes, this is network code. Slides are being sent over the network, and
this will help tremendously in case the WiFi drops and the server and
client need to reconcile state; the server won't (hopefully) have to
wipe the client and send everything all over again.

As a side note, implement-slide will probably be a very lonely branch,
since that kinda depends on this branch. Sorry, bud.
Merge branch 'master' into network-reliability
Merge branch 'network-reliability'

I'm going to work on the network code concurrently with implementing the
graphics code, since they're so intertwined.

Networks
Multi-threading
Graphics
These are a few of my favorite things...
AAAAAAAAAH