Reduce stub-ld build time closure

[Atemu]

@vcunat pointed out in #269551 that due to stub-ld's build-time dependency on pkgsStatic for both 64bit and 32bit, there is a large build-time closure for NixOS tests which is painful for bisecting NixOS tests in staging.

stub-ld is a very simple c-program whose entire purpose it is to print a user-friendly error message when the global dynamic is attempted to be invoked.

I see a few options:

1. Don't use a stdenv. The program is so simple that we could conceivably just invoke the compile and link commands manually.
2. Use nolibc instead of musl as @Mic92 recommended. We only need it to do a print.
3. Build it against the regular stdenv. I'm not quite sure why it's pkgsStatic actually. (cc @tejing1)

Regardless of these closure minimisations, we should look into disabling stub-ld for every NixOS test but the one which tests stub-ld itself. This really doesn't need to be tested in those as this is only ever invoked with binaries that assume a FHS which you should never find inside a NixOS test and even if you do, this is just a nicer error message.

[tejing1]

There's no particularly compelling reason why it's pkgsStatic. I needed the result to be statically linked, and that was how I knew to do it. Nothing more. No doubt there are much better ways to do it, and I really wasn't considering build closure size when I implemented it.

I agree that for this, it makes sense to do something more basic to reduce the build closure, but it's outside my expertise to do so.

[Mic92]

Old version of nix-ld where using nolibc before it was switch to the rust code base, if you need inspiration. glibcStatic might produce a bigger binary also not quite sure if it would be truly static after that (i.e. there glibc likes to load nss modules in some cases).

[Atemu]

What is the reason for needing it to be statically linked actually?

[tejing1]

Seems like the kernel (I think it's the kernel? My understanding of the roles in this space is hazy) doesn't support chaining ELF interpreters, from what I could tell. I did test if you could use a dynamic binary pointing at a loader in the store, and it didn't work.

[Mic92]

What is the reason for needing it to be statically linked actually?

They also need to be relocatable on top of statically linked because the actual elf binary is already mapped when the link-loader is executed. Chaining elf interpreter would be quite difficult to implement since it's unclear what state the first link-loader would left behind before entering the second one.