lmdb: ship static library, too

[thoughtpolice]

This is useful if you're using pkgs.pkgsMusl to build static libraries.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[thoughtpolice]

@GrahamcOfBorg build lmdb

[vcunat]

Hmm, there's the usual dilemma – keeping *.a with *.so will not be very nice for closures of the so-users. Here it's only 100 KiB so it doesn't matter much, but perhaps we might devise some general strategy in time.

---

Moving to another output is nice, but I suspect it makes often problems due to some tools assuming there's only a single library directory for a given library, e.g. the linker. Well possibly that particular tool could be fixed.

I expect the best way ATM of dealing with this would be to use separately built derivations for static and dynamic libraries, so you also get separate *.pc and such, and getting always only access to the one of the two that you want – perhaps via a standardized parameter. There was some discussion here as well: #41935

[vcunat]

@thoughtpolice: will this one work for your use case(s) instead? #79810

I did test pkgsStatic.lmdb looks good. (That has the advantage of being set up as fully static with musl.)