lib: add makeOverridableWithName + build*Package overrides

[B4dM4n]

Motivation for this change

Improve the extensibility of language specific package builders.

Some of current build*Package functions support more overriding capabilities than others:

• buildPythonPackage supports overriding packages via makeOverridable and overridePythonAttrs
• buildLuarocksPackage and buildRubyGem support overriding packages via makeOverridable
• buildRustPackage and buildPerlPackage supports no overriding

In theory makeOverridable should be enough to make a builder function overridable, but in practice this doesn't always work, because another callPackage might shadow the wanted override function.

buildPythonPackage works around this by providing a overridePythonAttrs function which is essentially a override with a custom name.

Things done

This PR adds a lib.makeOverridableWithName function, which is just lib.makeOverridable with a additional named override function.

It also adjusts the build*Package functions that I'm familiar with to use the new helper.

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• 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 nixpkgs-review --run "nixpkgs-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)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[FRidh]

Good initiative! But.... Do we actually need another override option? Maybe we should just ensure the custom builders use .overrideAttrs?

I still need to extend this, but please have a look at the RFC regarding this topic NixOS/rfcs#67. Please also have a look at the links in the PR which may give more context.

[infinisil]

I think this would be a great idea, I've had something like this in mind for a while, as it might be the only way to not need a dozen different override mechanisms for nested function calls. Thanks for bringing this up @B4dM4n, I'll definitely push for something like this in the future