Improved Java phantom references

[ThomasHaas]

This PR reworks the handling of phantom references in the Z3 API.

The previous implementation used N different reference queues, each with a IdentityHashMap to associate to each phantom reference the native z3 object it reference counts.
In some extreme cases, the IdentityHashMap's performance could degenerate, for example, if a user propagator creates millions of formulas in a short time (every fixed-callback creates at least 2 phantom references right now!)
Furthemore, Java's IdentityHashMap does not implement shrinking, so that the map can permanently consume a lot of memory even if emptied.

The new implementation replaces the hashmap with a doubly-linked list consisting of custom subclasses of phantom references.

Advantages:

• The doubly-linked list has a strictly smaller memory footprint in all cases and has no issues with shrinking. It also avoids the boxing of a long.
• The new phantom references have true constant-time handling as opposed to amortized constant time (no O(n) map enlargements, and no high access times in degenerate cases with high number of hash collisions)
• The N different reference queues are combined into a single reference queue for all objects (managed by Context). Instead, there are N different implementations(*) of PhantomReference all of which are directly inlined in the class they reference count (e.g. AST contains ASTRef). This puts the implementation of incRef and decRef in the same class for better maintainability.

Disadvantages:

• None. As far as I see, the new implementation is superior in every aspect: performance, memory, and maintainability.

(*) There is an even easier implementation that uses a single PhantomReference implementation that stores a method reference to the decRef implementation (rather than using subclassing). This variant stores an extra pointer per reference which increases memory consumption by ~14% and makes the implementation not strictly more memory efficient than IdentityHashMap (in most practical cases it will still be better) (EDIT: it is still strictly better since it avoids the boxing of a long).

Disclaimer: I have not yet tested the correctness of this new implementation. However, I have implemented and tested a slightly easier version in JavaSMT (this version reference counts only AST objects). Still, some testing should be done before merging.

[ThomasHaas]

Do I need to change update the python scripts that build the .jar (I don't know why the CI fails)?

[NikolajBjorner]

Need to update CMakeLists.txt for cmake build

[NikolajBjorner]

Thanks, I will check with java examples manually around Tuesday. I am not sure they get tested on the build.