UV3 Represent Feature Structures as Java Objects

Switch the storage model for Feature Structures to align with Java's Object Model, while preserving backwards compatibility.

This allows garbage collection of Feature Structures.

There is likely a performance benefit by having the data in one place only, with no conversions needed between the Java world and the data-on-the int-heap world of V2.

JCasGen capability (optional) will create Java fields representing the Feature values; getters will become simple get operations. Setters are more complex due to the need to support things like index corruption checking and journaling (when using Delta Cas operations).

Types without JCasGen'd classes will use generic Java class representation and store their features in a couple of local collections.

Mixing of these two approaches is also possible; e.g., the built-in type Annotation defines begin / end fields, which are represented as Java fields. Additional features may be represented by subtypes having no JCasGen'd class definition, and those fields would be saved in the generic local collections.

The goal is to support fast/efficient access both with and without JCas-gen'd classes.

Assign for each new Feature Structure created in a CAS, an incrementing ID, starting at 1. This id may be retrieved using a new FeatureStructure method get_id().

Name new internal fields and methods to start with an underscore to avoid collision with user-defined feature names, which cannot start with an underscore.

Update CASImpl to remove heaps, remove (unused) FSCache mechanism. Update JCasImpl to remove JCasHashMap, always have built-ins as JCas cover objects (load them even if JCas isn't being used). Convert Generators to use Java 8 method handles. Add method handle bridge from non-JCas feature access to JCas object access (where JCas objects exist), for getters and setters.