lib.types: fix loaOf behavior for long lists

Assigning a list of 10 or more elements to an option having the type
`loaOf a` produces a configuration value that is not honoring the
order of the original list. This commit fixes this and a related issue
arising when 10 or more lists are merged into this type of option.

lib/tests/modules/loaOf-with-long-list.nix

@@ -0,0 +1,19 @@
+{ config, lib, ... }:
+
+{
+  options = {
+    loaOfInt = lib.mkOption {
+      type = lib.types.loaOf lib.types.int;
+    };
+
+    result = lib.mkOption {
+      type = lib.types.str;
+    };
+  };
+
+  config = {
+    loaOfInt = [ 1 2 3 4 5 6 7 8 9 10 ];
+
+    result = toString (lib.attrValues config.loaOfInt);
+  };
+}

lib/tests/modules/loaOf-with-many-list-merges.nix

@@ -0,0 +1,19 @@
+{ config, lib, ... }:
+
+{
+  options = {
+    loaOfInt = lib.mkOption {
+      type = lib.types.loaOf lib.types.int;
+    };
+
+    result = lib.mkOption {
+      type = lib.types.str;
+    };
+  };
+
+  config = {
+    loaOfInt = lib.mkMerge (map lib.singleton [ 1 2 3 4 5 6 7 8 9 10 ]);
+
+    result = toString (lib.attrValues config.loaOfInt);
+  };
+}