core: frontend: make "version management" consistent

### Current behaviour

We currently have multiple different approaches for managing versions of things in BlueOS, which is unintuitive, and means some services miss out on functionality that seems quite obvious.

In particular:
- `BlueOS-core` versions can be updated in the basic BlueOS Version page, and selected and installed (including with selection of the dockerhub repo) and removed when in Pirate Mode, and a failed startup automatically falls back to a known 'factory' image, which currently [cannot be (nicely) changed](https://github.com/bluerobotics/BlueOS/issues/1613)
- `BlueOS-bootstrap` can have new versions installed to match the currently active `BlueOS-core` image, if it's newer than the bootstrap version
- This one is perhaps reasonable, just noting it for completeness
- BlueOS Extensions can be installed and updated through the manager, but there's no interface option to switch between installed versions, or to flag versions that are no longer wanted and can be deleted
- This is a poor user experience, and extra important once people can pay for extensions, because if a user updates to a version they only have temporary access to (or to a broken/buggy version) then they should be able to restore back to one they have full access to / that they know works
- It's currently quite inconvenient to [manually upload a docker image and register it as an Extension](https://github.com/bluerobotics/BlueOS/issues/1614)
- Autopilot firmware versions are not stored or switchable between
- This is extra relevant now that PX4 is getting integrated, because a user could want to try a different firmware type but then be able to switch back to their normal known good one (although that may also happen as-is when trying out a beta firmware or whatnot)
- Support is [currently limited](https://github.com/bluerobotics/BlueOS/issues/2178) for switching between different firmware types that are compatible with an available flight controller board

### Expected or desired behaviour

Ideally we would have similar features available for everything that has versions, and also have consistent interface elements for managing those features, so that there's less to learn, and the interface feels familiar and trustworthy to users.

### Prerequisites

- [X] I have checked to make sure that a similar request has not already been filed or fixed.

The issue does not name files, tests, or a specific entry point. Begin by reviewing the existing version-management interfaces for BlueOS-core, Extensions, and autopilot firmware, then read linked issues #1613, #1614, and #2178. Done requires an agreed and implemented approach for consistent version selection, installation, rollback, and removal.

Written by the indexing model from the issue text.