feat: add environment metadata file sysand_env/env.toml

[victor-linroth-sensmetry]

This PR adds a env.toml containing metadata for the projects installed in the local environment
(inluding editable projects not present inside the sysand_env folder).

Each project has the following fields:

• publisher: String (optional).
  Publisher of the project. Intended for display purposes.
• name: String (optional).
  Name of the project. Intended for display purposes.
• version: String (required).
  Version of the project.
• path: String (required).
  Path to the root directory of the project.
  If the project is not editable this should be relative
  to the env directory and otherwise it should be relative
  to the workspace root.
• identifiers: Array of strings (required for non-editable projects)
  List of identifiers (IRIs) used for the project.
  The first identifier is to. be considered the canonical
  identifier, and if the project is not editable this
  is the IRI it is installed as. The rest are considered
  as aliases. Can only be empty for editable projects.
• usages: Array of strings.
  Usages of the project. Intended for tools needing to
  track the interdependence of project in the environment.
• editable: bool.
  Indicator of wether the project is fully installed in
  the environment or located elsewhere.
• files: Array of strings (only for editable projects).
  In case of an editable project these are the files
  belonging to the project. Intended for tools that
  are not able to natively parse and understand the
  projects .meta.json file. Paths should be relative
  to the path of the project.

The current implementation doesn't change how projects.txt works and is intended to offer a
transition step between env structures. The env.toml isn't directly managed by
LocalDirectoryEnvironment since such a thing will likely require a change in the
WriteEnvironment trait. In particular it would have to offer the ability to give alias identifiers
in addition to the main IRI used for installation (since we want to communicate the dependency
structure between projects we need all aliases as well, at least if we want to incrementally add
or remove from the environment).

Example:

# This file is automatically generated by Sysand and is not intended to be edited manually.

version = "0.1"

[[project]]
name = "SYSMOD"
identifiers = [
    "urn:kpar:sysmod",
]
version = "5.0.0-alpha.2"
path = "a0aacee34dd4cd5e2d07ab43d5e30772ec86dbf3c8fafb033bad338dd7a0f02e/5.0.0-alpha.2.kpar"
usages = [
    "urn:kpar:analysis-library",
    "urn:kpar:cause-and-effect-library",
    "urn:kpar:data-type-library",
    "urn:kpar:function-library",
    "urn:kpar:geometry-library",
    "urn:kpar:metadata-library",
    "urn:kpar:quantities-and-units-library",
    "urn:kpar:requirement-derivation-library",
    "urn:kpar:semantic-library",
    "urn:kpar:systems-library",
]

[[project]]
name = "Testing"
version = "0.0.1"
path = "."
usages = [
    "urn:kpar:sysmod",
]
editable = true
files = [
    "test.sysml",
    "test.kerml",
]

[andrius-puksta-sensmetry]

Information provided (if available) includes

• Publisher
• Name
• Directory/Files
• Usages

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

[victor-linroth-sensmetry]

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

Well, our solution for name collisions is to use namespaces(/publishers). If you don't use them, then you don't get the solution.

[daumantas-kavolis-sensmetry]

This is communicated through a "resolved manifest" current.toml

current.toml is very non-descriptive or sounds quite irrelevant to an environment. env.toml or projects.toml would be far clearer.

In particular this means paths are absolute

I highly suggest using paths relative to manifest/sysand_env for paths inside sysand_env and project folders as majority of the paths will have an identical prefix that can trivially be removed.

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

Why would anyone care about collisions in what is effectively a display name? If a user has multiple projects named the same, they have bigger issues than some ambiguous name.

[daumantas-kavolis-sensmetry]

Maybe also add workspace = [0, 1, ...] top-level property that controls workspace/project roots for analysis?