This can be used for aspect introspection or for passing metadata
attached to aspects themselves.

---
@drupol would love your input on this one, does this look good to you?

Makes it possible to use the user class in `includes`, for example:

```nix
{ lib, ... }:
{
_heitor.user =
let
username = "heitor";
in
{
user.description = "Heitor Augusto";
nixos.sops.secrets."${username}/password".neededForUsers = true;

includes = [
(
{ host, ... }:
lib.optionalAttrs (host.class == "nixos") {
user =
{ osConfig, ... }:
{
extraGroups = [
"networkmanager"
"wheel"
];

hashedPasswordFile = osConfig.sops.secrets."${username}/password".path;
};
}
)
];
};
}
```

In current main, it fails:

```
[nixos@nixos:~/infra]$ nix flake check
warning: Git tree '/home/nixos/infra' is dirty
warning: ignoring untrusted substituter 'https://heitor.cachix.org', you are not a trusted user.
Run `man nix.conf` for more information on the `substituters` configuration option.
warning: ignoring the client-specified setting 'trusted-public-keys', because it is a restricted setting and you are not a trusted user
error:
… while checking flake output 'nixosConfigurations'

… while checking the NixOS configuration 'nixosConfigurations.axolotl'

… while calling the 'head' builtin
at /nix/store/xaknai40sz4yyy5658prwrwmfycj4xvm-source/lib/attrsets.nix:1712:13:
1711| if length values == 1 || pred here (elemAt values 1) (head values) then
1712| head values
| ^
1713| else

… while evaluating the option `system.build.toplevel':

… while evaluating definitions from `/nix/store/xaknai40sz4yyy5658prwrwmfycj4xvm-source/nixos/modules/system/activation/top-level.nix':

(stack trace truncated; use '--show-trace' to show the full, detailed trace)

error:
Failed assertions:
- Neither the root account nor any wheel user has a password or SSH authorized key.
You must set one to prevent being locked out of your system.
If you really want to be locked out of your system, set users.allowNoPasswordLogin = true;
However you are most probably better off by setting users.mutableUsers = true; and
manually running passwd root to set the root password.
```

closes #369

Fixes #378

---------

Co-authored-by: Victor Borja <vborja@apache.org>

Fixes #373

Follow-up to #368

Fixes #367

Signed-off-by: Michael Utz <theutz@users.noreply.github.com>
Co-authored-by: Victor Borja <vborja@apache.org>

Signed-off-by: Michael Utz <theutz@users.noreply.github.com>

Fixes #252

Fixes #352

## Summary
Providers when imported through a namespace get pass through a functor
transformation in `nix/lib/namespace/nix:functorModules` which fails to
propagate its `__functionArgs` for the reflection needing in the context
propagation system. Adding this alone is not enough because then this
triggers the freeformType part of the aspect type definition resulting
in a `__functionArgs` like this. The fix as far as I can tell also
requires registering the `__functionArgs` type with the aspect type.

```nix
__functionArgs = {
imports = [
{
_file = "<unknown-file>, via option den.ful.test.aspect.provides.host.__functionArgs";
imports = [
{ host = false; }
];
}
];
};
```

---------

Co-authored-by: Victor Borja <vborja@apache.org>

Signed-off-by: Victor Borja <vborja@apache.org>

Signed-off-by: Pol Dellaiera <pol.dellaiera@protonmail.com>

Usage Example:


```nix
# foo -> [bar]
den.ctx.foo.into.bar = { foo }: [ { bar = 22; } ];

# aspect for configuring foo
den.ctx.foo.provides.foo = { foo }: <aspect>;

# aspect for configuring bar
den.ctx.bar.provides.bar = { bar }: <aspect>;

# NEW: foo contributes configuration to bar
# The aspect here can read from both source and target contexts
den.ctx.foo.provides.bar = { foo }: { bar }: <aspect>;
```

## Changeset Summary

### Moved forward into nix/lib

`forward` proved to be a core combinator, moving it to lib allows to be
used outside of Den's NixOS framework.

### Forward based Ouputs

Now all `nixosConfigurations`,`homeConfigurations`,etc are now generated
via `forward` itself, accumulating into a `flake`-class module

### Flake System Outputs

Den now supports exposing to flake outputs via aspects.

The following classes were added (each named after the corresponding
flake output attribute): `packages`, `apps`, `checks`, `legacyPackages`,
`devShells`. All these are per-system outputs.

Usage:

See `templates/ci/modules/features/forward-flake-level.nix` for all
tests

```nix
den.aspects.foo = {
packages = { pkgs, ... }: { inherit hello; };
devShells = { pkgs, ... }: {
default = pkgs.mkShell { buildInputs = [ pkgs.hello ]; };
};
}

# Enable flake output attributes
imports = with inputs.den.flakeOutputs; [ packages devShells ];

# Include aspects that produce per system flake outputs:
den.ctx.flake-system.includes = [ den.aspects.foo ];
```

You can also make all your hosts produce flake-level outputs by simply
creating a context transition `{ system }` -> `{ host }`:

```nix
den.ctx.flake-system.into.host = { system }:
map (host: { inherit host; }) (lib.attrValues den.hosts.${system});
```

### `flakeOutputs.*` modules. See #317

Den now provides the following modules under `inputs.den.flakeOutputs.*`

- `flake`: creates a generic `options.flake` top-level option. Used only
when no `inputs.flake-parts` is available to avoid collision with
flake-parts.
- `nixosConfigurations`: creates `options.flake.nixosConfigurations`
- `darwinConfigurations`
- `homeConfigurations`
- `packages`: creates per-system `options.flake.packages`
- `apps`
- `checks`
- `devShells`
- `legacyPackages`

You will only need to import these on your flake (like we did in the
previous code example) if you want to enable those flake outputs being
written by Den.

### `den.systems` option

This option is used by `den.ctx.system` to know what systems to produce
outputs for.
It default to `config.systems` (flake-parts top-level system if it
exists), or systems of `den.hosts` + `den.hosmes`, or if those were
empty: `lib.systems.flakeExposed`

### nvf-standalone using packages output

Our nvf example was the first iteration on producing packages from Den
aspects, it has been updated to use `den.ctx.flake-packages` now.

Checks if the command is `home`, and if so, properly formats the
arguments so that `nh` will be able to switch to the specified home.

Fixes #253

Adds support for functionArgs inside the IntoPath arg of
den.provides.forward.
Includes tests for both home manager and nixos (might be a bit
overkill?).
Also fixes a typo in the documentation `permanance -> permanence`

**usage example:**
```nix
sysPersist =
{ host }:
{
class,
aspect-chain,
}:
den._.forward {
each = lib.singleton class;
fromClass = _: "sysPersist";
intoClass = _: host.class;
intoPath =
_:
{ config, ... }:
[
"environment"
"persistence"
config.impermanence.persistence-dir
];
fromAspect = _: lib.head aspect-chain;
guard = { options, ... }: options ? environment.persistence;
};
```

---------

Signed-off-by: Gelei <juinen@tuinberg.nl>
Co-authored-by: Victor Borja <vborja@apache.org>

Signed-off-by: Pol Dellaiera <pol.dellaiera@protonmail.com>

Signed-off-by: Victor Borja <vborja@apache.org>

### Upgrade path

`flake-aspects` input is no longer needed by Den.

```diff lang=nix
- inputs.flake-aspects = "github:vic/flake-aspects";
```

Den's `den.lib.aspects.resolve` API was simplified:

```diff lang=nix
- den.lib.aspects.resolve "nixos" [ aspect ] aspect;
+ den.lib.aspects.resolve "nixos" aspect;
```

---

### Den now has its own aspect types and resolve.

Previous versions of Den used `flake-aspects` as dependency. However as
Den evolved it was pushing the `flake-aspects` lib beyond its original
purpose, it also meant that people had to take care about what version
of `flake-aspects` they were using.

Den now bundles its own `lib/aspects/*.nix` library. Taken from
`flake-aspects` but free
to evolve and be optimized for Den specific requirements:

- `flake-aspects` default functor is `__functor = aspect: ctx: aspect;`,
however Den's default functor is `__functor = parametric`.
`flake-aspect` has no concept of Den different families of
`parametric.*`.

- Den's `aspect.resolve` generates a flat include list of modules. It
will later be optimized for specific Den features: synthethize `_file`
for better error reporting of values produced by Den aspects.
Optimizations for very very deeply nested includes via trampolines
`lib.genericClosure` + `lib.deepSeq` in the future.


- This makes Den library and framework to have zero dependencies which
is a huge usability point. (except of course, Den's `flakeModule`
expects being included in a module system where nixpkgs lib is
available).

---


Along with that, this PR also removes unused code and tries to simplify
some parts while keeping all 199 tests green without changes.

Removed flake-parts dependency from our CI trying to speed it more.

Our current limitation is `lib.evalModules` + `lib.nixosSystem` speed,
since each `denTest` creates a completely fresh den evaluation. We still
need to find better ways to profile Den evaluation times.

Reverts vic/den#337