Some people might be linking to gettext-runtime using intl.lib, while
others might be using libintl.lib (such as vcpkg builds), depending on
how gettext-runtime was built.  Add LIBINTL_LIB to the configurable
items, which defaults to intl.lib, in the NMake Makefiles so that we
can override it if needed in the NMake command line.

See #485 (comment 556977) for a
discussion on this.

This will enable us to stop using the rsvg.symbols file for our Visual
Studio builds.

Rsvg-view is a pretty crappy SVG viewer.

Also, it adds a GTK dependency on librsvg.  This makes the whole
dependency graph awkward, since GTK indirectly depends on librsvg via
gdk-pixbuf.

I think we are better off encouraging people to use image viewers that
are actually well-written and pleasant to use, like EOG.

Make things more consolidated.

Since the NMake Makefiles are in place, we can drop everything that is
related to the Visual Studio projects, which have been superseded.

This adds a set of NMake Makefiles, which will replace the Visual Studio
projects, so that we can have a more flexible build setup, and would be
usable for Visual Studio 2013 and later.

This also has the advantage to build optional items (such as rsvg-view-3,
which requires GTK, Introspection, and PangoFT2 support for the test
programs) on demand in one go, and adds a target 'tests' to build and
run the test programs in tests/ for librsvg.

This NMake Makefile set should cover all the build features that are
handled by the current Visual Studio projects.

This will also enable the removal of the autotools 'dist hook'
directives that are being used to generate the complete Visual Studio
projects, as we are now able to share source listings with the autotools
build files directly, which will be done in the upcoming commit(s).

As we are going to integrate win32/rsvg-rust.mak into our NMake
Makefiles, we need to remove its 'all' target and re-name our 'clean'
target.

We want to ensure that we can build with Visual Studio 2019 properly.

We are now using i18n stuff here, so we must link to gettext-runtime
as well.

The librsvg DLL now requires items from cairo-gobject, so make sure that
we link to it.

We need to go into $(srcroot)/rsvg_internals to do the cleanups, as
well.

Later versions of Rust include the Rust architecture in the output
directory by default (i.e i686-pc-windows-msvc or
x86_64-pc-windows-msvc), so we must include that in the output path in
both the NMake Makefile that is used to call cargo, as well as in the
rsvg-rust project, so that the librsvg DLL can properly link, and to
avoid running Cargo again when the Rust portion has been successfully
built.

Use the HIGHENTROPYVA linker option on x64 builds to enhance the
security of the built binaries.

Pointed out by Ignacio Casal Quinteiro.

As the recommended way to setup Rust is via rustup, set the default
toolchain/target during the NMake build process, so that one will only
need to have the Rust executables in their PATH and ensure that they
have the needed toolchains (i686-pc-windows-msvc and/or
x86_64-pc-windows-msvc) installed via rustup.

Please note that we are being conservative here-we use the stable
releases of the toolchains only.  If using a beta/nightly toolchain
release, one needs to update this file for this purpose.

Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues.  Fix this by:

-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x

This makes it easier for build systems that demand for the presence of .pc
files (such as Meson) to find packages.

Integration into the Visual Studio process will follow, this uses Python
to generate librsvg-2.0.pc.

This is done so that we can use this info to generate .pc files for Visual
Studio builds.

PangoFT2 (and thus FontConfig) are not required portions of the GTK+ stack
on Windows, but since the tests currently rely on this, make it easier for
people who want to build with FontConfig to build the tests.

The previous move of the projects to win32/ missed updating this part.
Fix this.

Move the projects to win32/ from build/win32/, so that one will need to go down
one less level down the tree to reach the project files, and will allow the
autotools modules (Makefile.msvcproj, Makefile-newvs.am,
Makefile.msvc-introspection) to be in sync with the ones in GLib and G-I master.

This also makes the support of Visual Studio 2017 complete by allowing it in the
NMake Makefiles, which is a must for this package since NMake Makefiles are used
to build the Rust bits on Visual Studio, as well as for introspection builds.