This is to avoid confusion with the PYTHONPATH envvar that is commonly
used to determine where additional Python modules can be loaded,
especially in the case of a MSBuild build. Note that envvar names are
not case sensitive on Windows in general.
glib-genmarshal is now a Python script instead of a compiled program, so
we need to:
-Remove the projects that are used to build the glib-genmarshal sources.
-Generate the full glib-genmarshal Python script from glib-genmarshal.in
-Make Python a hard build-time requirement, since we use this tool
in many parts of the stack (and it is the case for glib-mkenums).
-Tell people in the Visual Studio build README.txt files that Python
2.7.x or 3.x is now required for the build/"install".
The latest upstream libffi is getting bit-rotten with the Windows/MSVC
builds, and since we are eventually moving to a Meson-based build system,
make use of the Centricular fork of libffi[1], which is better maintained
and tested for builds on Windows, with the use of DLLs over static libraries
and elimination of awkward build flags that we had to use for GObject.
[1]: https://github.com/centricular/libffi
Use the new gen_util_scripts.py script to generate the glib-mkenums and
gdbus-codegen scripts with the proper info in them so that they can be
used properly by other build systems such as Meson, during "install".
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
