Add test for "rename to" annotation for records

https://bugzilla.gnome.org/show_bug.cgi?id=675985
Implement "rename to" annotation for records

https://bugzilla.gnome.org/show_bug.cgi?id=675985
Moving the early annotation pass is needed to avoid
the first type resolve pass to resolve to the not-renamed type.
tests: Fix comment about expected result
gimarshallingtests: Squash compiler warning
Regress: Update expected gir for previous changes
Windows port: Ensure ld can locate the libraries the temporary binary links

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: fix Python shebang lines

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: Make g-ir-annotiotion-tool, g-ir-doc-tool and g-ir-scanner 'relocatable' at runtime.

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: Monkeypatch subprocess.Popen

But only when executed in an MinGW/MSYS context. This makes sure
all subprocesses (via subprocess.Popen/call/check_call) are
automatically wrapped by "sh.exe -c", simulating an unbroken
chain of msys programs -> there's no msys-python port atm, so we're
forced to use the native windows Python port for g-ir-scanner during
build time. This is not ideal, but it works.

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: Monkeypatch os.path.join

But only when executing in a MinGW/MSYS context.
This ensures backslashes are automatically replaced
by forward slashed so we don't trip up MSYS quoting
rules.

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: pass arguments through a file

Convert POSIX style path names to Windows path names. Normally, this
conversion is done for us by MSYS when spawning a non-MSYS binary from
an MSYS binary, but we're completely sidestepping the usual argv handling
due to the 8192 character command line length limit imposed by CMD.EXE (or
more likely the API used by MSYS bash)...

https://bugzilla.gnome.org/show_bug.cgi?id=620566
[WIP] Windows port: pass arguments through a file

This needs to be used on MinGW/MSYS only, but how?

https://bugzilla.gnome.org/show_bug.cgi?id=620566
[WIP] Windows port: use the correct crt for Python 2.5, 2.6, 2.7 and 3.2

A more appropriate solution would be to decuce this in python.m4,
but let's work around this limitation for now.

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: replace a stray backslash with a slash.

Like the FIXME sais: this is hackish, but I don't know a
better way to do this...

https://bugzilla.gnome.org/show_bug.cgi?id=620566
Windows port: fix tempfile .exe extension

Temporary executables where wrongly named xexe
instead of x.exe.

Thanks to Earnie Boyd <earnie@users.sourceforge.net>
for reporting this.
Windows port: fix OpenBSB porting fallout

win32 Python does not have os.uname(), so check if it
exists before checking for OpenBSD thus fixing an
AttributeError.
Windows port: ensure export-all-symbols is correctly passed on to the linker

Fixes "/mingw/mingw32/ld.exe: warning: cannot find entry symbol xport-all-symbols; defaulting to 00401000".
Clarify LibtoolImporter's load_module method

It was reported by HeBD on #introspection that Python modules
use the .pyd extension on windows, not .dll.

The simple fix would have been to just rename to .pyd, but we
started investigating the possibility of acquiring the suffix tuple(s)
via imp.get_suffixes() instead. Which led to the discovery that
imp.load_module() ignores the first item of said tuple. Thus,
there is no use in pretending it to be of any importance in this
case so we set it to an empty string.

imp_load_module() source for:
Python 2.5: http://hg.python.org/cpython/file/b48e1b48e670/Python/import.c#l2827
Python 2.6: http://hg.python.org/cpython/file/62fa61f2ee7d/Python/import.c#l3021
Python 2.7: http://hg.python.org/cpython/file/0c10061df711/Python/import.c#l3025
Add support for PyDev remote debugger.
Remove support for old libtool versions, we depend on 2.2 anyway.