Cabal should factor the libc used to build a package into the hash of the package

**Describe the bug**
Right now, `cabal-install` will place all packages in the package cache or `dist-newstyle` under `build/`, for example `build/arm-linux`. This works fine if there is only one libc you are targeting. If you have multiple devices with different libc's, but the same architecture, then what could happen is the wrong objects will be pulled in during the build.

For example, I have two routers that I deploy on right now, one with glibc and one with musl. If I build with glibc, then switch over to musl, the main project gets rebuilt but the dependencies don't -- and the glibc-targeted artifacts are pulled into my musl build. This usually results in undefined symbol errors at link time. To work around this, I just have to delete `dist-newstyle/build/arm-linux` and possibly a dependency or two in `/home/shane/.cabal/store/ghc-8.10.1/`. (like `cryptonite-0.26`, for example). That will trigger a rebuild with the correct libc targeted.

**To Reproduce**
Steps to reproduce the behavior:

The easiest way I can think of to reproduce this involves cross compiling with two different toolchains. On Gentoo here, I have a glibc-based ARM and musl-based ARM toolchain.

First, cross compile a package with the glibc toolchain:
` cabal v2-build --allow-newer --with-ghc=armv7a-hardfloat-linux-gnueabi-ghc --with-hc-pkg=armv7a-hardfloat-linux-gnueabi-ghc-pkg`

That ought to work fine. Now, cross compile a package with the musl toolchain:
` cabal v2-build --allow-newer --with-ghc=armv7a-hardfloat-linux-musleabi-ghc --with-hc-pkg=armv7a-hardfloat-linux-musleabi-ghc-pkg`

Now, you might start seeing compilation errors show up, like the following:

~~~
Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
- XSaiga-1.6.1.0 (exe:solarman.cgi) (first run)
Preprocessing executable 'solarman.cgi' for XSaiga-1.6.1.0..
Building executable 'solarman.cgi' for XSaiga-1.6.1.0..
Linking /home/shane/workspace/solarman/dist-newstyle/build/arm-linux/ghc-8.10.1/XSaiga-1.6.1.0/x/solarman.cgi/build/solarman.cgi/solarman.cgi ...
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(cryptonite_sha512.o): in function `cryptonite_sha512t_init':
cryptonite_sha512.c:(.text+0x147c): undefined reference to `__sprintf_chk'
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(ed25519.o): in function `expand256_modm':
ed25519.c:(.text+0x51c0): undefined reference to `__memcpy_chk'
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(cryptonite_sha3.o): in function `cryptonite_sha3_update':
cryptonite_sha3.c:(.text+0x274): undefined reference to `__memcpy_chk'
collect2: error: ld returned 1 exit status
`armv7a-hardfloat-linux-musleabi-gcc' failed in phase `Linker'. (Exit code: 1)
~~~

I suspect this may have to do with the fact that some libraries have C code which is built with `FORTIFY_HEADERS`, a glibc macro in this case. This causes the code to be linked against functions such as `__memcpy_chk`, which are glibc specific and don't exist in musl.

To work around this, all one has to do is, in this case, `rm ~/.cabal/store/ghc-8.10.1/cryptonite-0.26-*`, which will then trigger a rebuild of that package. It *seems* like the package hash doesn't take into account the libc used to build that package, and so it simply pulls in the wrong compiled package from the cache.

**Expected behavior**
Cabal should take into account the libc used to build a package and recognize that as the same as if the package flags itself had changed somehow (say, the toolchain changed, or debug symbols are requested, or a package specific flag changed, etc).

**System information**
- Gentoo, testing, GentooLTO configuration
- cabal git latest (3.3), ghc 8.10.1

**Additional context**
I realize that this might be a really esoteric thing, but it would make cross compiling with cabal easier. The package that I'm working on is XSaiga, which has a lot of different dependencies, but I could distill this into a minimal working example if needed.