Bump nixpkgs to latest master

[nomeata]

This PR is a lot of work…

• Bumps nixpkgs to latest master
• Because of that, a lot of Haskell related version bumps and other stuff can go
• Also, all nixpkgs patches can be dropped. Leave nixpkgs-patching code in place, but improve so that it does not do anything if there are no patches.
• Simply cabal2nix machinery; no need to repeat list of packages mentioned in nix/generate.nix
• Use .gitattributes to mark generated files as such
• Maintenance of the non-nix workflow that pushes the docs.
• The static Haskell build no longer worked, but with ghc on musl: Crude hack to allow integer-simple NixOS/nixpkgs#138429 it does again. Yay!

[nomeata]

I am a bit stuck now, and the problem is the static build of ic-ref, which ships with dfx.

Previously, I used a compiler built against musl (via nix’s pkgsMusl), which allows static linking just fine. But this broke at some point in nixpkgs (see NixOS/nixpkgs#129606 (comment), although there isn't much information).

I tried to use pkgsStatic instead, but that fails because then GHC cannot do Template Haskell, as dependencies have no .so files in this configuration.

I could try haskell-nix-static, but that’s yet another dependency, and I am worried about keeping the versions in sync between that and nixpkgs.

It would be easiest if we can just drop the static build. I am not sure what the plans with the emulator in dfx are; we never advertised it. Is it still used and useful, @ericswanson-dfinity?

[nomeata]

Finally green!

I suggest to squash merge using the PR description as the commit message (this is what mergify would do, maybe we should start using this.)

Also, I'd appreciate admin rights again, like I have on Motoko, so that I can do such maintenance and infra work more easily. Who do I need to ask about that?