common: Ensure we use $(CC) from environment when compiling scanned binaries

GNU make will default to "gcc" if "cc" isn't found; we need to
replicate that behavior here.

Patch-suggested-by: ojab <ojab@ojab.ru>

https://bugzilla.gnome.org/show_bug.cgi?id=678678
Python3-friendly python.m4

https://bugzilla.gnome.org/show_bug.cgi?id=678728
scanner: Ignore #defines starting with _

This matches our behavior for symbols (and we should probably fix this
more globally...I think we still scan _-prefixed enums).

Noticed from gudev which had #define _GUDEV_INSIDE_H 1

https://bugzilla.gnome.org/show_bug.cgi?id=674072
docs: Show correct path used by g-ir-scanner

Signed-off-by: Colin Walters <walters@verbum.org>

https://bugzilla.gnome.org/show_bug.cgi?id=668193
cmph: Remove C99ism and other fixes

...So that it will compile on non-C99 compilers.  The changes are mainly
moving the variable declarations to the start of the resecptive blocks.

Also, replace the use of buflen in chd.c as it might not be defined for all
platforms, instead using packed_cr_size as it seems to represent the value
that is to be printed/displayed by the debugging output.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
girffi.c: Don't include unistd.h unconditionally

It does not exist on all platforms

https://bugzilla.gnome.org/show_bug.cgi?id=681820
giscanner/scannerparser.y: Avoid C99ism

Move variable declarations to the start of block.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
girepository: Remove C99ism and other updates

-Make code using libgirepository_internals relocatable on Windows,
 like what is done in the GTK+ stack, and the girepository DLL.
-Remove C99isms
-"interface" is a reserved keyword on certain compilers, so change that to
 "giinterface"

https://bugzilla.gnome.org/show_bug.cgi?id=681820
giscanner/dumper.py: Use os.name instead of os.uname()[0]

os.uname is not available universally, so use something that exists
universally.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
giscannermodule.c: Updates for Windows

-Incorporate and extend Dieter's patch regarding possible different CRTs
 used in Windows Python (msvcrt71.dll for Python 2.5, msvcrt90.dll for
 Python 2.6- 3.2, and msvcrt100.dll for Python 3.3+) vs. the CRT used to
 build g-i (msvcrt.dll for MinGW/WinDDK, msvcrt90.dll for stock MSVC 2008
 and msvcrt100.dll for stock MSVC 2010)
-Avoid C99ism for NEW_CLASS as we are having an array without a
 pre-determined length.  There might be better ways to get around this
 though.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add a pre-configured config.h.(win32.in)

This adds a pre-defined config.h for Windows builds, but versioning info
are updated by autotools.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add girepository.symbols

This is the listing of symbols to export from the main libgirepository
.dll/.so.  This is used for example to generate the .lib file from the
Windows DLL.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add .def files for building the various DLLs (.la's) in test\

This will enable the exports of functions to create the .lib files needed
to create the .gir files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
giscanner/sourcescanner.py: Update for Visual C++ usage

Since the Visual C++ (cl.exe) preprocessor does not accept source input
from stdin (the '-' preprocessor flag, we need to use the GCC preprocessor
as a helper here.

Note that the generated dumper program is still compiled and run by
Visual C++.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
sourcescannermain.py: Add --filelist option

Add a function to put the files to pass to g-ir-scanner in a filelist
file, with one source/header file on a single line.  This is done to
work around the limitation of Windows cmd.exe (and MSYS) where the command
line cannot exceed 8192 characters.

When this option is used, g-ir-scanner will only look for the header/source
files that are specified in the filelist file, which is not too hard to
generate.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add a test_gir_cmd.txt file

This is to show how one may be able to generate the .gir files from the
various DLL files in tests\ in a standard Windows cmd.exe prompt, which
will also attempt to demonstrate how .gir files are generated without a
shell.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add README.txt files for Visual C++ builds

Add instructions to tell people how to build gobject-introspection with
Visual C++, especially as there are special steps and additional
requirements for a successful build.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add Visual Studio projects

These are the Visual C++ 2008/2010 project files that can be used to build
gobject-introspection.  The main girepository dll (along with cmph), tools
(in C), certain test/sample programs dlls are built with this project file
set.

Due to a bug in the Visual C++ 2008 linker, the g-ir-compiler and
g-ir-generator tools have the libgirepository-internals sources built
along side with the sources of these respective tool programs.

In order to ease future maintenance, the cmph, girepository,
g-ir-compiler and property sheets (for the "install" part) are done as
templates where header/source listings are filled in during "make dist",
so that the headers/sources listings are kept up to date between releases.

The GLib and girepository .gir and .typelib files are also generated and
"compiled" as part of the build process, using gengir.bat that
was committed earlier.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Add Visual Studio 2008/2010 Solution files

These are the master solution files that will load the Visual C++ projects
for building/generating gobject-introspection and its related tools and
files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820
Update autotools for Visual C++ projects creation

-Add Makefile-msvcproj.am to fill in the cmph, girepository and
 g-ir-compiler projects
-Add various Makefile.am's under build/ to distribute the
 Visual C++-related files.

https://bugzilla.gnome.org/show_bug.cgi?id=681820