lib/attrsets: merge concatMapAttrs recursively

[SuperSandro2000]

This makes it possible to drop name and just inherit values.

concatMapAttrsRecursive (name: value: { inherit (value) a b; }) { foo = { a = { q = null; }; b = { q = null;  }; bar = { a = { p = null;  }; b = { p= null; };};};}

Before the above only returned { a = { q = null; }; b = { q = null; }; } and with that change p is also included.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.11 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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[figsoda]

I would suggest having an additional concatMapAttrsRecursive function instead

[roberth]

Also skip ahead to the concatMapAttrsRecursiveUntil variant, because recursive merging/updating without knowing the meaning of the attrsets is bad.
For example, you might accidentally merge packages, where an attribute that's unique to the lower package ends up in the end result that's mostly the upper package. Good luck figuring out that bug.

[SuperSandro2000]

Added the recursive variant, don't really have the time to do a until variant right now.

[figsoda]

Suggested change

	concatMapAttrs ::
	concatMapAttrsRecursive ::

[infinisil]

What are the use cases for such a function?

[roberth]

I take back my previous comment. A truly recursive concatMapAttrs would not just merge one layer of values recursively, but merge each layer of values recursively. This is how I misunderstood this PR.

Instead of recursion, the new function seems to be about combining attribute values instead of picking one, so I think zipWithAttrs is the appropriate alternative to a "recursive" concatMapAttrs.
Perhaps this alternative could be documented in concatMapAttrs.