CI: rescue appveyor config from old-master and backup others

[piponazo]

In this PR I am recovering the Appveyor configuration from old-master which is covering more cases than the previous one. Also, the Github PR page is now pointing to the correct Appveyor instance (before it was pointing to some Robin's personal instance).

Currently, the Appveyor configuration only had 3 jobs with different versions of Visual Studio and always the same configuration:

• Visual Studio 2019 - x86_64 - Shared Lib - Release
• Visual Studio 2017 - x86_64 - Shared Lib - Release
• Visual Studio 2015 - x86_64 - Shared Lib - Release

I think it is more interesting to have different configurations but use always the latest Visual Studio since we are sure all these versions of Visual Studio fully implement C++11 (The previous configuration was saved at ci/appveyor_all_vs_versions.yml as a backup):

• Visual Studio 2019 - x86_64 - Shared Lib - Release
• Visual Studio 2019 - x86_64 - Shared Lib - Debug
• Visual Studio 2019 - x86_64 - Static Lib - Release
• Visual Studio 2019 - x86_64 - Static Lib - Debug
• Visual Studio 2019 - x86 - Shared Lib - Release
• Visual Studio 2019 - x86 - Shared Lib - Debug
• Visual Studio 2019 - x86 - Static Lib - Release
• Visual Studio 2019 - x86 - Static Lib - Debug

Thanks to this change I could fix few deffects:

• Conan: When using gtest on debug mode, I had to remove the debug_postfix, otherwise CMake was not finding the library provided by conan.
• Conan: Keep the usage of the old Expat recipe. On windows there are problems to find the libraries.
• CMake: Ignore LINK warnings 4099 about missing PDBs on 3rd party dependencies. We are not interested at the moment in generating fully working PDBs on Windows / Debug releases.
• Code: fix some warnings detected in debug mode.
• Testing code: Increased timeout. Windows Debug releases are very slow and they were timing out.

[hassec]

Which CMake version are we stuck with due to older distributions?
Does it maybe make sense to move to a newer one, and simply have the older distributions download a newer version?

[piponazo]

On Debian:9 the default CMake version is 3.7 and on CentOS:8 it is 3.11.

I am the first one I would like to use the latest CMake version possible, but in practice I think this would make more difficult for distributions to include the latest Exiv2 version (need to create patches, and so on). But being honest, I am just guessing, I do not know how distribution maintainers consume and generate binaries for each of the distribution packages.

Most of the times (like this one) it is only about tiny details, and the quality of the CMake code does not get affected (too much). If we find a good excuse/reason to require a CMake higher version, we can always discuss it in a separate issue/PR 😁

[hassec]

Sounds reasonable to me! It's always a trade-off :)
As long as it's not impacting our CMake too much I think you are right, no reason to upgrade just yet :)