[NO MERGE] Testing upstream fixes for HDF5 detection

[dopplershift]

Testing potential upstream CMake fixes so that hopefully the next release is easier.

cc @WardF

Checklist

• Used a personal fork of the feedstock to propose changes
• 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 @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[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.

[dopplershift]

See Unidata/netcdf-c#2095.

[WardF]

@dopplershift It looks like the most recent checks failed for a new/unrelated reason. Could we restart them and see if the issue persists or if it was a one-off thing?

[WardF]

I've fixed the appveyor issue over on the netcdf-c repo; once we figure out the windows cmake issue here, I'll get everything merged back in together.

[dopplershift]

@WardF the failure was actually due to the patch failing to apply. I've changed how I'm generating it to now baseline against the v4.8.1 branch rather than master--plus a couple manual edits. I'd expect this one to work better.

[WardF]

@dopplershift Thanks! I appreciate your help in tracking this down. It looks like all the tests are passing, is there anything else on your end before I can check this off and merge the PR back over at Unidata/netcdf-c?

[dopplershift]

I'm just waiting to see Drone pass (aarch64) to call this complete.

[dopplershift]

Alright, hopefully this should make getting 4.8.2 built upon release much easier.