feat: relative directory usage type

[andrius-puksta-sensmetry]

This PR introduces support for referencing local directory paths as project dependencies, alongside the existing IRI/URL-based usages. It also refines the resolution API to carry richer context and adds an experimental CLI subcommand to expose the new capability.

New Directory usage type

A new variant Directory { dir, publisher, name } is added to InterchangeProjectUsageG. It serialises as {"dir": "relative/path", "publisher": "...", "name": "..."}. It only supports local_src projects. KPARs will use another type. This is to keep resolution unambiguous. It allows avoiding resolution altogether for typed usages, although currently resolution is still done.

ResolutionInfo replaces IRIs

ResolveRead now takes a ResolutionInfo instead of an IRI. ResolutionInfo wraps InterchangeProjectUsage and an optional base_path for resolving relative filesystem paths. A custom Hash implementation is included so that pubgrub identifies packages by identity (publisher + name) rather than version constraint, preventing the same package from appearing multiple times in the solution when it has different constraints/path in different dependents.

experimental CLI subcommand (sysand/src/cli.rs)

Adds sysand experimental add --dir <path> and sysand experimental remove <publisher> <name>:

• add computes a path relative to the current project, populates publisher/name from the dependency's .project.json, and creates a Directory usage.
  Currently no source overrides are supported by this command. It does not seem useful to support this at add time, considering that typed usages will support everything supported by source overrides, so these usages can be added directly instead of going through overrides.
• remove removes a project by its publisher and name. This will work for all usage types that include a publisher and name, currently I plan for all typed usages to have this for consistency.

Commands are separate from regular add/remove to avoid breaking changes; also it's not clear how the UX will work for other usage types (add especially), so this leaves room to experiment.

[vytautas-astrauskas-sensmetry]

It serialises as {"dir": "relative/path", "publisher": "...", "name": "..."}.

Why are publisher and name fields needed? In Cargo, as far as I understand, only path is used to specify the dependency and name is provided to be able to rename the dependency from the user's side.