TST/CI: Add post-install tests for CMake, pkg-config, and geos-config

[mwtoews]

The primary objective with this PR is to test installing GEOS on a host, and run post-install tests that build and link apps based on the installed library. CMake, pkg-config, and geos-config solutions are tested independently. Autoconf and automake are also tested from a CMake-built library.

This largely supersedes #346, when autotools was natively supported.

See Trac #1113.

[mwtoews]

Ready for review for anyone willing to go thru a patch with C/C++/Autoconf/Automake/Make/CMake/POSIX sh/Windows BAT/YAML in it.

The non-GitHub linked CI tests have not been verified yet.

[pramsey]

This is a very large and finicky piece of work to bring in, touching as it does every CI target. Having done only small and easy bits of CI work and seen them eat multiple days each time I shrink from picking this up on pure laziness grounds. Do we break external build frequently?

[mwtoews]

Two recent issues that I've discovered while developing the previous post-install tests include:

1. gh-347
2. gh-326

Probably most of these would have eventually been picked up on an alpha/beta/RC phase, but not always.

The post-install tests can also be run on other installations of libgeos, e.g. from conda. Just run the script with a different prefix.

[mwtoews]

Because there's lots going on in this PR, here is my English version of the methods:

There are three ways to link a program to libgeos:

1. CMake via find_package(GEOS REQUIRED) (docs)
2. geos-config used in (e.g.) a Makefile, like using geos-config --cflags to set CFLAGS
3. pkg-config used in (e.g.) a Makefile, or Autoconf via PKG_CHECK_MODULES([GEOS], [geos]) (docs)

In the post-install suite, there are two trivial "apps" that are built against libgeos:

1. C app using the C API, checked by all three methods
2. C++ app using the C++ API, checked by CMake and geos-config methods (but not pkg-config)

Besides testing a successful compilation, each build goes through two checks:

1. The programs just print the GEOS version to stdout, so check this output against what is known by CMake/geos-config/pkg-config
2. Where possible, check the output of ldd (or whatever is native) to check that it contains a reference to libgeos / geos.dll. I'm not sure how MSVC does this, so these tests are skipped.

The checks are written using CTest (in the CMakeLists.txt files) or POSIX sh for geos-config/pkg-config (Automake supports a handy TESTS variable).

[pramsey]

@robe2 any chance I can suck you into this? You have visibility into more CI envs than anyone else...

[robe2]

@robe2 any chance I can suck you into this? You have visibility into more CI envs than anyone else...

Sorry just saw this. I haven't read thru it all but can probably look at it in a week or so.

[mwtoews]

@robe2 I haven't mentioned here, but I'm already scheming a 3rd version of this test suite that checks static and dynamic libraries. It's on my laptop, but not done yet. So a review can wait until it's ready.

[robe2]

@mwtoews Where did we leave off on this?

[mwtoews]

It's still on my todo list. Let's close this one for now, and I'll open a new PR when ready. It should look similar to the one for PROJ.