Removes Id Len

Commented out the portions of code which gave a limitation to how long
a clients ID could be (8).  It came to pass that the length of the ID
was needed to be passed in the socket message which is contained to a
byte.  So technically there is a limit at 255 characters so I left the
code in there for the time being and instead just commented out the
check.
Changes to Key Chars and Bug fix

I decided to remove the letters 'i','I','l','L', and 'O' since it can
be difficult to interpret what exactly is what in the given context so
this made life easier.

There was also an 'off-by-one' error in parsing the id/key file where
the new line character was being included in the key which led to some
issues.
Socket issue fixes

There was an issue with the if/else statements in regards to figuring
out if the socket had closed or if there was an error which was part of
the issure of the program throwing an obscure error about thread events
when you closed the server.  It is only partially fixed at the moment
but I have a good idea of what needs to be changed in order to fix it.

Also parsing the data input for the length of the id string became
necessary so there is now a byte after the reqest message for the
length of the id that follows.  The id is required to pull up the
correct key for the given client id.
Client socket changes

Client socket now uses a more simplified 'BufferedOutputStream' instead
of the 'PrintWriter'  which is more condusive to binary writing;
specifically the hash check.  It also became more apparent that sending mouse
data in a binary format is more intuitive (and more effecient).

I hadn't noticed before the when shoving a byte array into the
PrintWriter object it was simply calling toString() on the byte array
which in turn reported the address at which the byte array was sitting
and not the contents of the array; woops, should've known better.
Challenge Changes

Fundamental to how the challenge was generated and transmitted.  It is
still emitting a failure when it shouldn't be but the string the client
is receiving seems to be making more sense.  Will require more
debugging.  This is priority number one.