feat: Implement mod versioning

[Alystrasz]

Implementation of R2Northstar/NorthstarLauncher#828 new manifest format, going from:

{
  "Parkour": false,
  "HUD Revamp v2": false
}

to:

{
  "Parkour": {
    "0.2.0": false,
    "0.2.1": false
  },
  "HUD Revamp v2": {
    "2.0.0": false
  }
}

If the current version of the manifest cannot be defined automatically, NORTHSTAR_MODS_MANIFEST_VERSION default value will be used instead.

(This is not a breaking change, as the current manifest format support is preserved.)

TODOs

• Fix set_mod_enabled_status with mods we don't know the version to enable/disable (e.g. core mods/mod settings)
• Add a manifest version parameter to rebuild_enabled_mods_json
• PR description
• Add testing instructions

Testing

With this contribution, Flightcore supports both manifest versions dynamically, which means you can switch between profiles using different versions with no issues.

To test this, I configured a R2Northstar profile with current manifest format, and a R2Development profile with new manifest format:

mod-versioning-support.webm

v0 (current format) manifest: enabledmods.json
v1 (new format) manifest: enabledmods.json

[Alystrasz]

@GeckoEidechse what should happen when flightcore can't load enabledmods.json file (thus not being able to determine manifest version being used)?
Should we rebuild enabledmods.json using v0 (old format) or v1?

[GeckoEidechse]

I'd say rebuild in v0 for now but have a feature flag or simple conditional check to tell it to rebuild in v1 instead. That way we can just "flip the switch" when we release the corresponding update in Northstar.

[GeckoEidechse]

Clippy CI errors are from update in Rust toolchain and will be fixed by #1053