devchk build problem gtk2 vs gtk3 (native)

devchk has generated test sources matching each LSB header. These are
compiled against a CFLAGS value (defined in cflags.mk) which contains
one set of includes for native build, a second set for LSB build.
However, these don't vary based on the source file being compiled.
devchk is a unique build in that it will contain both objects built
against gtk2 and ones built against gtk3.

There's a problem with the current setup for the native build when
headers include other headers, and those headers don't have unique base
names. The generated sources themselves include a header path with
enough detail not to be a problem, for example, gtk_3_0_gtk_gtk_h.c has

#include "gtk-3.0/gtk/gtk.h"

however, that header in turn has includes, and for the upstream case
those look like:

#include <gtk/gtkaccelgroup.h>
#include <gtk/gtkaccellabel.h>
#include <gtk/gtkaccelmap.h>

and we can see matches for these exist in two places:

/usr/include/gtk-2.0/gtk/gtkaccellabel.h
/usr/include/gtk-2.0/gtk/gtkaccelmap.h
/usr/include/gtk-2.0/gtk/gtkaccelgroup.h
/usr/include/gtk-3.0/gtk/gtkaccellabel.h
/usr/include/gtk-3.0/gtk/gtkaccelmap.h
/usr/include/gtk-3.0/gtk/gtkaccelgroup.h

So the build is going to depend on having been supplied the right
include path to pick the right one. So we can see that a common set of
include paths for every single source file to be compiled isn't going
to work out - if that common CFLAGS has -I/usr/include/gtk-2.0 only, or
before the gtk-3.0 version, then builds of the sources that want gtk-3.0
stuff will have some problems.

The LSB headers use the fuller paths, so this same build problem ought
not to occur in lsbcc mode.