Closes NixOS#193336
Closes NixOS#261694
Related to 108984

This pull request is a composite of the changes from NixOS#193336 and
also NixOS#261694, with some changes of my own that I made.

The goal here was to get the following flake to build and run on
`aarch64-darwin`:

```nix
{ inputs.nixpkgs.url = <this branch>;

  outputs = { nixpkgs, ... }: {
    checks.aarch64-darwin.default =
      nixpkgs.legacyPackages.aarch64-darwin.nixosTest {
        name = "test";

        nodes.machine = { };

        testScript = "";
      };
  };
}
```

… and after this change it does.  There's no longer a need for the
user to set `nodes.*.nixpkgs.pkgs` or
`nodes.*.virtualisation.host.pkgs` as the correct values are inferred
from the host system.

This change is spiritually much closer to the approach in NixOS#261694
than the approach in NixOS#193336.  However, I still made a few changes
compared to NixOS#261694:

- I didn't include the change to increase `ulimit`

  I think this change was questionable because I feel like a script
  provided by Nixpkgs shouldn't be tinkering with the user's ambient
  `ulimit` settings.

- I named the required system feature `hvf` instead of `apple-virt`

  I preferred the `hvf` system feature name chosen by NixOS#193336.

- I didn't use the `node.pkgs` setting to set `nodes.*.nixpkgs.pkgs`

  That does not work, based on my testing, but setting the same thing
  in `nixos/lib/testing/nodes.nix` does work.

- I created a `pkgsLocal` helper

  This is based on the feedback from @roberth here:

  https://github.com/NixOS/nixpkgs/pull/261694/files#r1365443955

  … and is similar in spirit to `pkgsCross`.

… as suggested by @roberth

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

… as suggested by @roberth

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

… as suggsted by @roberth

… as caught by @cole-h

… as caught by @robert

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

… based on feedback from @roberth

This plays nicer with other changes the user might want to make and
also works in conjunction with the `pkgsReadOnly`.

Note that this required deleting the `nixpkgs.pkgs` default because
that's not compatible with setting `nixpkgs.system`.  If `nixpkgs.pkgs`
is defined (even as a default-valued option) then `nixpkgs.system` is
ignored.

This is no longer necessary now that we're overriding `nixpkgs.system`
instead of `nixpkgs.pkgs`

Based on my local testing these options seem unnecessary and the VM
runs fine without them being set.  I originally cargo-culted these
from NixOS#261694 but they don't seem necessary.

Specifically, the `nixosTest-example` test correctly flagged that the
change from 90679ea broke the user's
expectation that the `pkgs` in `pkgs.nixosTest` would be reused as the
package set for the NixOS test system.

However, if we restore the original code removed by that commit:

```nix
nixpkgs.pkgs = lib.mkDefault pkgs;
```

… then that won't work because then we can't override `nixpkgs.system`
and reinstantiate that package set.  The whole *point* of this set of
changes is that we DON'T want to use the user's `pkgs` set as is
because then the wrong system is used for the NixOS test (on macOS).
Specifically, on Apple Silicon the `pkgs` in `pkgs.nixosTest` is going
to be instantiated with `system = aarch64-darwin;` but we want the
`nixpkgs.pkgs` that the NixOS machine uses to be that same package set
reinstantiated with `system = aarch64-linux;`.

Then I realized we can strike a balance by doing this instead:

```nix
nixpkgs.overlays = lib.mkDefault pkgs.overlays;
nixpkgs.config = lib.mkDefault pkgs.config;
```

… then we can get something which splits the difference: we preserve
the user's original package overrides but now we can reinstantiate
`nixpkgs.pkgs` with the new (correct) `nixpkgs.system`.

This isn't a foolproof solution, though, because `pkgs.overlays` and
`pkgs.config` do not necessarily contain all the information to
recreate the original `pkgs` that the user supplied.  As a concrete
example, if the user were to extend the package set "artificially" like
this:

```nix
(pkgs // { foo = …; }).nixosTest …
```

… then that `pkgs.foo` attribute would no longer be passed along to
`nixpgs.pkgs`.  However, in practice I believe most users are going to
be overriding `pkgs` using either the `config.packageOverrides` or
`overlays` arguments to the Nixpkgs function, so I think this is a
reasonable compromise.  Moreover, the benefit of this compromise is
that the NixOS test framework is much more "fire and forget" (we don't
need to instruct the users to instantiate Nixpkgs themselves twice for
the host and guest architecture).

I'd considered suggesting to add a conditional here, but that would
create VM-host-dependent portability issues for no good reason.

This solves the previously introduced evaluation performance
regression when evaluating multiple tests at once.

… as suggested by @cole-h