[foreign] RFR: cleanup binder code generation

[Maurizio Cimadamore]

Hi,
I took at stab at consolidating the binder codegen support; the patch I 
put together addresses 3 issues:

* The support for civilized bindings is less-than-half baked, and it 
should be removed. So I removed CivilizedHeaderImplGenerator and 
CivilizerAutoConversions. And I also removed the bind vs. bindRaw 
duality in the Libraries API. There's now only one version called 'bind' 
whose semantics is 'bind-raw'. This caused a flurry of small changes in 
tests.

* (minor) I moved the Argument class from the toplevel impl package to 
the ABI package, since that's where it belongs

* the meat of this patch is the removal of many of the code generator 
classes (I counted 8 of them). The rationale is that many of the things 
we do using FieldBuilders etc. are easily done using unsafe's constant 
pool patching (or condy, if we want to leave the unsafe world). The only 
reason for sticking things into static fields and then load them with a 
getfield is to generate code that is more scrutable (e.g. with javap), 
but I think this concern is not enough to justify keeping all these 
complex classes around.

The new code has a main BinderClassGenerator, with two subclasses: 
StructImplGenerator and HeaderImplGenerator - specialized in generating 
binder impl for struct and headers, respectively. They all rely on a 
tweaked ASM ClassWriter which allows CP patching.

Note: there's still a lot of code esp. in StructImplGenerator which I 
expect will go away as a result of further API changes and cleanup - 
e.g. right now array access is handled by the binder code spinning (!!), 
rather than by ReferenceImpl, but it's not worth cleaning that up given 
that our plan for arrays is quite different from what is implemented 
right now.

Webrev here:

http://cr.openjdk.java.net/~mcimadamore/panama/codegen-cleanup/

Cheers
Maurizio