Rewrite build.sh to use CMake instead of autotools

[mwtoews]

Checklist

• [X] Used a personal fork of the feedstock to propose changes
• [X] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [X] Ensured the license file is being packaged.

Summary of changes

• Closes #54
• CMake is the only build tool supported for future versions of GEOS; see RFC7
• Don't rename README.md (why? bld.bat for Windows doesn't do this)
• Run ctest for all platforms
• Minor edit to bld.bat to run ctest without -V, same as build.sh

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[gillins]

Hi @mwtoews . any chance this could change the symbols exported by the library? I worry this might break the ABI...

My feeling would be that it is safest to wait until a new version arrives (and we have to migrate dependent packages anyway). Unless there is some guarantee of ABI stability?

[mwtoews]

There are a few differences with the outputs from CMake vs. Autotools, see a related GEOS ticket #669. For instance, Autotools builds libgeos-3.9.1.so while CMake builds libgeos.so.3.9.1. The C API should remain stable, but there is never a guarantee for the C++ ABI stability.

I don't mind holding this PR as a draft until the next GEOS release.

[gillins]

I don't mind holding this PR as a draft until the next GEOS release.

That sounds like a good plan! I think we need to be pretty careful with this in case we break something. Any idea when a new release will be ready?

[mwtoews]

Not sure when next release is due, as it's not as regular as PROJ, but I follow the mail list so will see any announcement.

[mwtoews]

Will add commits from this PR into #61