buildPgrxExtension: restructure with lib.extendMkDerivation

[diogotcorreia]

This PR enables buildPgrxExtension to take finalAttrs: { ... } with the help of lib.extendMkDerivation introduced in #234651.

I migrated the pgvecto-rs extension to validate the implementation. All cargo-pgrx extensions have been migrated

The PR should yield no rebuilds.

Related discussion: #392710 (comment)
cc @wolfgangwalther

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

The large diff block is due to indentation changes, while the effective diff is minimal. Commit-by-commit review is much easier.

If you change GitHub's diff settings to "hide whitespace", the second commit becomes empty. Thus, you don't need to split the first two - reviewing the whole PR with "hide whitespace" works very well.

[diogotcorreia]

@wolfgangwalther TIL, thanks for telling me, squashed the two commits
I had copied the idea from a similar PR for buildRustPackage 😅

[wolfgangwalther]

I plan to look at this, but I am not familiar with lib.extendMkDerivation, yet. So I will have to look into that first - my plan is, to refactor postgresqlBuildExtension to use it as well, and then review here with my gained knowledge. Once I find the time..!

[wolfgangwalther]

Let's refactor the remaining 3-4 pgrx packages to use finalAttrs, too - shouldn't be too much effort.

In #398194, I refactored all those with postgresqlBuildExtension, combined with this we'd have all of them :)

[diogotcorreia]

Done :)
And fixed merge conflicts