[foreign] RFR 8220163: jextract drivers used in jtreg tests should not depend on platform specific headers

[Maurizio Cimadamore]

Hi,
in an attempt to make our jextract tests more reliable across platforms 
and test environments, I went ahead and added the -nostdinc option to 
the various jextract drivers we're using:

http://cr.openjdk.java.net/~mcimadamore/panama/8220163/

Two comments:

* since <complex.h> is not in the set of standard header provided by 
LLVM (which we can rely upon), I removed reference to 'complex' and 
replaced them with __Complex (which is a keyword in C99, sadly not 
supported by MSVC)

* LibProc is also depending on availability of system headers at test 
execution time - so I've ignored it for now; we can rewrite it in the 
future by simply writing the annotated interfaces it needs by hand.


In general, there are various degrees of portability in tests:

1) the test extracts no external header - then it's totally portable

2) the test extracts some external headers which are defined in the 
<jdk-root>/conf/jextract folder - the test should be portable with 
reasonable confidence

3) the test relies on some native compilation (e.g. compilation of a 
shared native lib) which relies on a standard header (e.g. in stdlib) - 
that should be portable enough (note we're not running jextract on the 
header here, we're just compiling the library during the build, when we 
DO have the headers)

4) the test attempts to extract some libraries not in 
<jdk-root>/conf/jextract; the cross-platform behavior is unspecified; 
could work on some platforms, not on others and, even with same 
platforms, you might be at risk of depending on specifics of the machine 
running the test (e.g. is MSVC installed or not)


So, this patch tries to move away from (4) into any of the other (1, 2, 
3) approaches, which are significantly more portable and robust.


Another way to make (4) safer, would be to run jextract on the headers 
at build-time (in the same way native shared test lib are also built at 
build-time). This is probably a better idea longer term, but it likely 
requires lots of build hackery to get there. As such, this patch looks 
like a reasonable compromise to get to a better place, but suggestions 
are welcome, of course.

Maurizio