or else at least the following config will fail with an evaluation error
instead of an assert

```
{
  services.nixosManual.enable = false;
  services.nixosManual.showManual = true;
}
```

Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:

  { config, lib, ... }:

  {
    options.foo = lib.mkOption {
      type = lib.types.bool;
      default = true;
      description = "...";
    };

    options.bar = lib.mkOption {
      type = lib.types.bool;
      default = false;
      description = "...";
    };

    config = lib.mkMerge [
      (lib.mkIf config.bar {
        system.build.bar = "foobar";
      })
      (lib.mkIf config.foo {
        assertions = lib.singleton {
          assertion = config.bar;
          message = "Bar needs to be enabled";
        };
        systemd.services.foo = {
          description = "Foo";
          serviceConfig.ExecStart = config.system.build.bar;
        };
      })
    ];
  }

This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.

The original pull request references a breakage due to the following:

  {
    services.nixosManual.enable = false;
    services.nixosManual.showManual = true;
  }

However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.

Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.