Implemented a basic RMI-like protocol/language, calling it ARMI.

ARMI stands for Alternative Remote Method Invocation.

The goal is to be a legible, simple alternative to full Java RMI, while
supporting a similar set of features.
Got rid of the whole "package path" concept.

There was no good reason to keep the package and the class name as separate
entities.
Continued refinements, added JUnit tests.
Big overhaul, lots of updates.

Unfortunately, this was not properly documented as it happened, but here is a
summary of what appears to be the important changes:
 * Added HELP and LIST commands to make API discovery easier.
 * Added an UNSOL (unsolicited) message type, allowing a server to send
   information to the client without a corresponding client-initiated request.
 * Added an array type and a null value.
 * Allow empty argument lists.
 * Allow empty field lists.
 * Renamed CommandException to SyntaxException, as it may occur in a request
   that is not strictly a command (i.e. HELP or LIST).
 * Renamed Command to CallCommand, as Command is now the supertype for all
   requests (i.e. CALL, HELP, and LIST).
 * Similarly, Error is now ErrorResponse and Value is now ValueResponse.
 * Added a bunch of new tests.
Removed the LIST command and added a default API library.
All commands must now end in EOF.

Note: Two tests are currently failing.
Corrected an error in the HELP command grammar.

Help commands were parsing into an incorrect tree layout.

This fixes the test failures introduced by the previous commit.
Log each argument in AbstractLanguageObject as it is converted.
Properly escape quotes and backslashes during object serialization.
Prevent NPEs while parsing empty arrays.
Include the component type of arrays in the serialized format.

This way we can restore arrays to their original type, instead of just
using Object[], which would not work in most situations.

Note: Three tests are currently broken.
Allow serialization of Collections and Maps.

This does not play nicely with generics, however, because numbers will be
converted to Longs or Doubles, but the receiver may expect them to be of
a smaller type. Need to modify NUM to record which numeric type it is
storing.

Note: Three tests are still broken from the previous commit.
Update DefaultClassRegistry so it falls back onto the system classloader.

This allows for a simpler registry in many cases, as things like
java.lang.Integer and similar don't need to be registered before they can
be used for arrays.

This fixes the previously broken tests.
Include type with less usual numeric types.

Byte (B), Short (S), Long (L), and Float (F) get type postfixes so they
deserialize appropriately. This should fix the problem with Collections
using the incorrect type.
Include normally inaccessible fields in serialization.

By turning on the accessible flag for all fields during serialization, and
for all included fields during deserialization, we can include their values
even if they are protected, default, private, or final.

We still do not include static, or transient fields.
Change easily misread numeric postfixes, and correct escaping.

Byte is now Y, because B looks too much like 8. Similarly, Short is now T
because S looks too much like 5. Y and T do not really look like any numbers
(well... T sort of looks like 7, but not as much as S and 5 are similar).
Write declared fields in alphabetical order.

Not using declared fields skips inclusion of protected, private, ...

Writing in alphabetical order makes testing easier, since we know the exact
order of fields in a known object, so we can continue to use simple string
comparisons.

Note: Two tests are currently broken.
Rewrite test class for test cases as multiple classes.

This make introducing tests for new features easier, because there is a
good chance that you can just add a new test class.

Note: This fixes the broken tests.
Tweak test classes to be more fragile in the face of errors.

By only setting initial values on fields if a special constructor is called
(which is not called during deserialization), we can catch the case of the
deserialization not touching the object at all.

Also, rearranged TestCase to be clearer.
Add tests for collections and maps.