Add osx arm64

[schmoelder]

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.

For reference, I tried to follow this guide: https://conda-forge.org/blog/2020/10/29/macos-arm64/

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

[schmoelder]

@conda-forge-admin, please rerender

[sleweke-bayer]

That's going to be a tricky one: As far as I know, Azure only has x64 Macs and, hence, cross-compilation is used to produce the arm64 binaries.
Since we need the templateCodeGen for the build, we also compile it to arm64. When executing, we are greeted by

/bin/sh: ../build-tools/templateCodeGen: Bad CPU type in executable

[schmoelder]

Thanks for the insight, I didn't really understand what was going on. So let's hope this will soon be resolved upstream. For reference, this seems to be the relevant issue: conda-forge/conda-forge.github.io#1781

[MementoRC]

Does templateCodeGen really need to be compiled on the host? I am having a similar issue on another recipe and was directed to a recipe that builds the tools on the build instead: https://github.com/conda-forge/gazebo-feedstock/blob/8a60c5a155a1660e42388cd06318dcfb30bc7c8b/recipe/build.sh#L1-L26
hope this can help

[sleweke-bayer]

Thanks for the suggestion, @MementoRC. Indeed, compiling templateCodeGen for the host machine would be feasible as it is only used for code generation at build time.
This will require some CMake changes upstream (or a patch here) to allow providing an external templateCodeGen.