refactor: project model using targets, features and environments

[baszalmstra]

First refactor to support multiple environments.

This PR refactors the internal project model and adapts the code to use it. The concept of a Feature and a Target is introduced. At the moment when parsing the project manifest a "default" feature is created which is used throughout the code.

Note

to reviewers, this is a first PR of a few to come. I want to quickly and iteratively land PRs. This is not the final result.

Feature

In the multi-env story Features describe a set of dependencies/tasks/etc. This concept was also introduced in the project model. At the moment there is only one default feature (described by all the keys at the root of the toml) but the project model already supports multiple features which we can use in a follow-up PR.

Target

A target encapsulates everything that you can find in for instance a [target.win-64] table. The same datastructure is reused for elements "at the root" e.g.

[dependencies]

is internally rewritten to

[target."default".dependencies]

where "default" has a special meaning.

Targets is a datastructure that encapsulates a collection of targets and allows querying which targets apply in certain situations. E.g.

[dependencies]
..

[target.linux-64.dependencies]
...

Targets will hold two Targets, the default target ([dependencies]) and the linux-64 target. You can request all applicable targets for a certain platform and it will return these two targets in order of most specific first.

Environment

Environment is already part of the model (with a default one being created) but it is not yet used throughout the rest of the code. A followup PR will refactor the codebase to always use Environments to derive the tasks, dependencies and system-requirements currently available.

Tests

The PR refactors a lot of snapshot tests. Since the project model is now very different from the toml layout the debug snapshots
often didnt make a whole lot of sense. I changed most of the tests to more closely verify the actual expected result of certain operations instead of "just" outputting a snapshot. Hopefully this makes them less prone to change with future iterations.

[ruben-arts]

[target.win-64.hostdependencies]

Is now accepted but before it would throw:

➜ ~/.pixi/bin/pixi i
  × failed to parse pixi.toml from /home/rarts/development/pixi
  ╰─▶ failed to parse project manifest
    ╭─[pixi.toml:40:1]
 40 │ 
 41 │ [target.win-64.hostdependencies]
    ·                ────────┬───────
    ·                        ╰── unknown field `hostdependencies`, expected one of `dependencies`, `host-dependencies`, `build-dependencies`, `pypi-dependencies`, `activation`, `tasks`
    ╰────

[baszalmstra]

@ruben-arts Should be fixed now!

[ruben-arts]

Amazinggggggggggg