Exposes packages to constraints

[arcanis]

What's the problem this PR addresses?

Constraints can only operate on the workspaces' listed dependencies, but have no idea about the shape of the global dependency tree. In general it's enough, but I wanted to write a constraint autofixing missing peer dependencies, and this wasn't possible without knowing the dependencies of our dependencies.

How did you fix it?

I added a concept of "package" to the constraint API. Some of their characteristics:

• They are based on the resolved dependency tree; as a result, there is no direct concept of devDependency / dependency (just like in the core Package type).

• They somewhat look like the Package type, but with fewer information (just the dependencies & peer dependencies, at the moment), and with a slightly different format (no need for serialization, so it directly references other data structure rather than go through string hashes).

• They don't provide any autofix (or even reporting) capability at the moment. Perhaps later I'll add an error API, like regular dependencies, but that'll probably require to enhance them so they are able to access the packages' filesystems, so it'll have to be a follow-up.

Testing is currently lacking ... like the rest of the JS constraints engine 😶‍🌫️

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.