Namespace for inner classes in jextract

[Duncan Gittins]

Most likely this is a topic you've considered before when dealing with 
the namespace for jextract generated code, I hope this isn't re-opening 
issues.

When adding an extra "--filter header.h" to jextract generation all 
calling applications need to be re-compiled just in case the number of 
super classes above the top level class has  changed - as some inner 
classes may move between superclasses. Here is an example <init> stack 
trace from code which uses "Shell32_h.IShellLinkAVtbl" that was not 
re-compiled after generating a new (larger) jextract jar:

     Caused by: java.lang.NoClassDefFoundError: 
duncan/win/Shell32_h_3$IShellLinkAVtbl

Example jextracts show this comes about (simplied commands, not the one 
which caused above error):

      jextract -source -lshell32  -t duncan.win -d 
source\duncan.win\java.1 --filter shellapi.h --filter shobjidl_core.h  
-I "c:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um" 
headers\Shell32.h

     jextract -source -lshell32  -t duncan.win -d 
source\duncan.win\java.2 --filter errhandlingapi.h --filter shellapi.h 
--filter shobjidl_core.h --filter winuser.h  -I "c:\Program Files 
(x86)\Windows Kits\10\Include\10.0.18362.0\um" headers\Shell32.h

     grep -c -l IShellLink source/duncan.win/java.[12]/duncan/win/*
     source/duncan.win/java.1/duncan/win/Shell32_h.java
     source/duncan.win/java.2/duncan/win/Shell32_h_2.java    # 
IShellLinkAVtbl has moved

Instead of emitting many inner classes which are defined somewhere in 
the chain of the top level class+superclasses, have you considered 
creating these as top level classes (perhaps in a sub-package) so that 
their naming path would be consistent between jextract re-runs - thus 
reducing the need to re-compile all dependent applications?

Kind regards

Duncan