Growing jextract

[Maurizio Cimadamore]

I think I tend to agree with the general sentiment here (although, keep 
reading). While we'd like to provdie a well-defined semantics, in 
reality what jextract does is influenced by the limitations of the 
underlying libclang API (e.g. that is we jextract uses the underlying 
struct directly, in this case - we don't really have much choice).

But, that also means that developers would have to "learn" all the catch 
22s that are buried inside libclang... which isn't ideal.

If you pull on that string, I think you end up in a place where 
"include-XYZ" options are treated as "inclusion roots". If you get 
there, perhaps you'll be greeted with different surprises - e.g.

Foo *ptr;

Is "Foo" a dependency of the "ptr" declaration? (jextract doesn't 
strictly require that to generate good code).

And, if "Foo" is a typedef whose base type is "Bar", should we generate 
just "Bar" or both "Foo" and "Bar" ? (which probably runs into the 
limitation described above).

Note that if "Foo" is a typedef, and whose base type "Bar" is another 
typedef with base type "Baz", there is no way for jextract to see the 
middle type "Bar" (as that gets thrown away by libclang, which only 
allows to go the "underlying type" of a typedef - that is the final 
struct definition).

I'm a little afraid that, no matter what policy we pick here, is going 
to be weird/ad-hoc, depending on the use cases.

P.S.

> USB_DEVICE_DESCRIPTOR DeviceDescriptor;
>
> What needs to be included additionally?
>
Doesn't the new error tell the user _what_ needs to be included? Example:

```
struct Bar {
    int x;
};

typedef struct Bar Baz;

struct Foo {
    Baz baz;
};
```

Jextract says:

ERROR: Foo depends on Bar which has been excluded

So, it doesn't seem to like there's any guessing involved? It might 
perhaps be surprising that jextract is complaining about "Bar" and not 
"Baz" (at least when looking at the source), but at least the messages 
are consistent in driving the user in the right direction.

Maurizio