[foreign] RFR 8215211: cleanup JType/TypeDIctionary

[Maurizio Cimadamore]

Hi,
please review this jextract patch:

http://cr.openjdk.java.net/~mcimadamore/panama/8215211_v2/

The goal is to simplify the JType hierarchy and the TypeDictionary 
class. JType is currently a very rich hierarchy that is capable of 
modeling basically any clang type/cursor. In a way, JType is overlapping 
a lot with the recently added jextract tree representation; it feels 
like JType can be greatly simplified, and we can just rely on trees for 
structural info.

Simplifying the JType hierarchy has many benefits - in the patch you 
will notice that we no longer need a lot of instance tests and casts.

The second issue is with TypeDictionary, whose lookup/define logic is 
scattered across TypeDictionary and HeaderFile::define. There's also a 
very complex lookup scheme which starts from TypeDictionary::lookup and 
then ends up in Context then back to HeaderFile::define. This is all 
very hard to follow.

I've now centralized all type resolution logic in TypeDictionary, which 
now features two functions: lookup and enterIfAbsent, which internally 
share the same 'getInternal'. TypeDictionary will simply create a JType 
from a clang Type, and the only thing a TypeDictionary has to keep track 
of, is the use of the anonymous function types created during the 
'enter' phase. Note that such enter phase has now been moved into a 
proper tree visitor.

This simplify things quite a bit, to the point that 
AsmCodeFactory::addType becomes a simple visitor call. I think more 
rounds of cleanup are possible, but, to get there, we need to simplify 
the logic of Context/HeaderFile::processTree, which requires having a 
more precise mapping between clang compilation units and jextract trees. 
For instance, we currently parse everything into the same 'header tree', 
even if we end up generating multiple classes; secondly, we sorely miss 
a CallbackTree, so we have to do a lot of gymnastic in order to 
understand which classfiles need to be generated for functional interfaces.

Note: I seem to recall that function pointer typedef should emit, a 
named functional interface matching the name of the typedef. But the I 
noted that this is not the way things work in the current impl, so I did 
not bother too much with that (but I can address that if required, 
although doing so will cause breakages in tests, so I'd prefer to do 
that separately).

Cheers
Maurizio