lib.asserts.assertAll: init

[infinisil]

Description of changes

Split off from #209099 where this function is useful. It can also be used for #209375

This work is sponsored by Antithesis ✨

Things done

• Decided on the design
• Wrote docs
• Wrote tests

[infinisil]

Design decisions:

1. Should it be called with named arguments instead? E.g.

   # assertAll :: {
   #   condition :: a -> Bool;
   #   list :: [a];
   #   message :: Int -> a -> String;
   # } -> Bool
   assert assertAll {
     condition = n: n != 2;
     list = [ 1 3 5 ];
     message = i: n: "Index ${toString i}, value ${toString n} failed.";
   };

   RFC 135 also goes in that direction

2. Should the message have access to not only the first, but all elements that don't satisfy the condition? The module system has such a use case:

   nixpkgs/lib/modules.nix

   Lines 765 to 767 in 12053de

   	if all (def: type.check def.value) defsFinal then type.merge loc defsFinal
   	else let allInvalid = filter (def: ! type.check def.value) defsFinal;
   	in throw "A definition for option `${showOption loc}' is not of type `${type.description}'. Definition values:${showDefs allInvalid}"

   
   How should this look like? Maybe

   # assertAll :: {
   #   condition :: a -> Bool;
   #   list :: [a];
   #   message :: [{ index :: Int; value :: a; }] -> String;
   # } -> Bool
   assert assertAll {
     condition = n: n != 2;
     list = [ 1 2 3 ];
     message = failingElements: "Index ${(head failingElements).index}, value ${(head failingElements).value} failed.";

[fricklerhandwerk]

1. Yes, and to make it like RFC 135, it should be

assertAll = {success, message}: list: ...

2. Sounds good. Possibly with an index attached? Needs more thinking and discussion.