Correct cross-compiler support by using conda-provided compiler toolchain

[Areustle]

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)
• [x] 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.

resolves #20

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

[Areustle]

There were two problems with the previous implementation. First, the f2c Makefile uses hard-coded cc, ld, and ar tools to build the libraries. Thus it was missing the cross-platform-compilers provided by conda on the osxarm64 host, which is currently just an x86_64 box provided by azure. To address this I added sed substitution expressions to swap out the hard coded tools for those provided by conda in the ${CC}, ${LD}, ${AR} environment variables.

This was only partially successful, as it caused a related problem on the osx_arm64 host: This f2c Makefile compiles an intermediate program from arithchk.c which is subsequetly called to generate the arith.h header. If this binary is compiled with the arm cross-compiler it won't be able to run on the underlying x86 host, and will crash the build, as we saw with commit 21df98c. The solution is to get this compilation to use the ${CC_FROM_BUILD} compiler, which will work as expected on the base build machine.