Switch to CMake

[h-vetinari]

This PR is not immediately meant for merging, but for doing a logical separation of different changes on the way to exploratory emscripten support

[conda-forge-webservices]

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/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

Win-arm runs into conda-forge/vc-feedstock#83, rest is fine.

[h-vetinari]

After some more time, I actually think we should do this; definitely makes life easier & more consistent for translating to rattler adding emscripten etc.

I checked that the SOVERSION stays the same, so this should be OK also from an ABI point of view.

[isuruf]

You can keep experimenting here. That's okay. However, I am not going to merge this as a maintainer. Just checking the SOVERSION is not enough as you already know. I've sent you the list of things to check from our docs before. You should check everything on that list.
Besides that, if rattler build and emscripten can't handle a such a simple build system like zlib, and needs to switch to cmake, then those systems would be dead on water.
I talked about switching to rattler-build on @conda-forge/core meeting yesterday with @wolfv and the consensus was that if the maintainers were not comfortable with switching to rattler-build just yet, nobody should force them to. Given that zlib is a package that's there on almost every env, I'm not okay with switching to rattler-build in the near future (I might consider switching to new recipe format when conda-build supports it) or cmake here.

[h-vetinari]

If rattler build and emscripten can't handle a such a simple build system like zlib, and needs to switch to cmake

They don't need the switch to CMake, it's just way less of a hassle than dealing with autotools.