[foreign] road to posix

[Maurizio Cimadamore]

Hi,
in order to do some test of the new jextract support in the foreign 
branch, I've jextracted the dlfcn header and wrote this simple test:

```
import java.lang.invoke.MethodHandles;
import java.nicl.Libraries;
import java.nicl.Scope;
import java.nicl.types.Pointer;

public class TestDlfcn {

     static Pointer<?> RTLD_DEFAULT = Pointer.nullPointer();
     static posix.dlfcn dlfcn = Libraries.bind(MethodHandles.lookup(), 
posix.dlfcn.class);

     static void resolve(String sym) throws Throwable {
         dlfcn.dlerror();
         try (Scope sc = Scope.newNativeScope()) {
             Pointer<?> addr = dlfcn.dlsym(RTLD_DEFAULT, sc.toCString(sym));

             Pointer<Byte> errCode = dlfcn.dlerror();
             if (!errCode.equals(Pointer.nullPointer())) {
                 System.err.println(String.format("failed to resolve 
symbol %s: cause %s", sym, Pointer.toString(errCode)));
             } else {
                 System.err.println(String.format("symbol %s resolved at 
address %x", sym, addr.addr()));
             }
         }
     }

     public static void main(String[] args) throws Throwable {
         resolve("qsort");
         resolve("dlsym");
         resolve("localtime");
         resolve("dlsym1"); //error
         resolve("fsort"); //error
     }
}
```

This all worked nicely, I'd say I was impressed at how easy it was to 
jextract the header, and to create an intellij project with the required 
stuff. And it worked first time - here's the output:

```
symbol qsort resolved at address 7f8c5df30760
symbol dlsym resolved at address 7f8c5dada040
symbol localtime resolved at address 7f8c5dfb2930
failed to resolve symbol dlsym1: cause 
/w/lt/panama/dev/build/linux-x86_64-normal-server-release/images/jdk/bin/java: 
undefined symbol: dlsym1
failed to resolve symbol fsort: cause 
/w/lt/panama/dev/build/linux-x86_64-normal-server-release/images/jdk/bin/java: 
undefined symbol: fsort
```

There was a minor surprise though: the dlfcn header defines a bunch of 
constants which are necessary in order to work with the library; my 
example above uses RTLD_DEFAULT. Unfortunately, such constants are 
(unsurprisignly) defined as this:

```
# define RTLD_DEFAULT   ((void *) 0)
```

Since Jextract doesn't understand these, these constants are omitted 
from the jextract output. But this leads to usability issues, since 
constants that are crucial to be able to interact with this library are 
left behind - in fact I had to 'redefine' the RTLD_DEFAULT constant 
myself. This process is obviously error prone; while we do have a story 
for headers, that story is very complex and was mostly aimed at exposing 
function-like macros in headers; I wonder if we also need a separate, 
simpler story so that jextract can handle simple constants such as these 
and stick them into the extracted header?


Maurizio