Reintegrating branch "filteredCompress-uima-2498" into trunk

[Marshall Schor <ms...@schor.com>]

I've just reintegrated this branch into the trunk for uimaj (main SDK).

This branch has some slight reorganization of internal classes, and adds the
type-filtering compressed binary serialization capability talked about in Jira
UIMA-2498.

That facility is implemented along-side the previously introduced binary
compressed serialization, in order to continue to support (for backwards
compatibility) deserializing any compressed binary serialization done with the
previous method (code in BinaryCasSerDes4).  The new code is in BinaryCasSerDes6.

I've also added some sections to the docs on the new compressed serialization. 
I think I'm going to tweak the name of this slightly, from "type-mapping"
terminology to "type-filtering" instead, because the current impl only supports
non-identical type systems where the difference is restricted to omitting some
types and/or omitting some features with a type.

This has the advantage that if you have a remote service that uses just a small
subset of the types of its client, only those types will be sent to the remote
service, if this form of serialization is used.  (Note: there is no work yet to
switch over the uima-as serialization transport to use this - it is something
that we should do slowly and carefully, to flush out any remaining :-) bugs). 

I have to say this was a real challenge to write test cases for because there
are just so many conditions to check for.  Some of the test cases use random
numbers, running in a loop, to generate a large set of random variations to test.

While preparing for the reintegration merge, I was running the entire uimaj-core
test suite, and saw somewhat random failures in the compressed binary
serialization code - eventually traced to what looks like a Java bug.  I put in
a work-around.  For the curious, the bug is documented in line 1167 of the class
BinaryCasSerDes6.  It seems that under some circumstances, Math.abs(0x7fffffff)
(the largest positive number) was returning 0x80000000 (Integer.MIN_VALUE).  Of
course it didn't fail if I ran the tests using mvn test or ran from Eclipse
(right-click the test and say run as junit test) - it only failed if I ran the
whole suite of uimaj-core tests at once.  So - probably something to do with JIT
things...

-Marshall