Decouple the adapter of Java compiler server with the logic of testing

[zhiyuanshi]

The code for make test2 (namely FileLoad.hs, FileIO.hs) prevents code re-use and evolve because it awkwardly entangles two aspects:

• the part responsible for communicating with FileServer.java (the "service"), and
• the part that does the actual testing, e.g., compare actual outputs against the expected ones

Migrating to the Tasty framework (Issue #32) requires extracting the first part out as a "service adapter" (will call it JavaCompileServerAdapter). The service adapter is a Haskell client of the actual service written in Java and it provides service to other Haskell code.

Requirements:

1. The service adapter should just do one thing: compile a given Java source and returns the output; it shouldn't be aware of the other part of the code base, so that reuse is possible.
2. All communication with the Java compilation service should be made through this service adapter, and the communication protocol should be available only to the two parties: service adapter and service.