bug in TCompactProto python readMessageEnd method and updated test cases

The python implementation of TCompactProtocol has a bug in readMessageEnd, an assert on its internal state being READ_VALUE when it's actually CLEAR. I am including a patch that is 2 lines of library code change to TCompactProtocol.py, and a few dozen lines of ./test/py/ code changes.

Changes in this patch:

• fixed the readMessageEnd bug (2 lines)
• added TCompactProto to the list of target protocols for the test suite
• added a new --proto cmdline option to TestServer.py/TestClient.py to permit one of [accel, binary, compact]
• changed RunTests.py so it has a nested loop, trying each protocol with each server type
• added more client/server test methods for the ThriftTest service's: testNest(), testMap(), testSet(), testList(), testEnum(), testTypedef(), testMapMap(), testMulti()
• fixed a bug in testOneWay() that was being passed a float instead of an int
• added new TProcessPool class to list of servers and imports
  • added extra code to shut down the individual process pool workers, to avoid leaving the server listen socket bound
• added optional --port option to RunTests.py and TestServer.py so the port can be changed for both server & client from the RunTests.py cmdline
• added optional argument to RunTests.py to run just a single server type, i.e. ./RunTests.py --port=9092 THttpServer
• RunTests.py now prints out the exact cmdlines it executes for both server and client, to be more explicit
• RunTests.py checks to make sure the server process didn't fail (via serverproc.poll() & serverproc.returncode test) which was a 'fixme' note in the code

It takes a bit longer now for RunTests.py to execute, since it's testing 21 combinations of 3 protocols and 7 server type (with 3.5 extra seconds of shutdown time for the TProcessPool server type). It's ~35 seconds now to run the whole suite, but gives more thorough code coverage for the tests.