core: frontend: Allow user to provide arguments for ArduSub executable

### Current behaviour

The Ardusub executable provides users with a myriad of flags and options, however BlueOS' ardupilot-manager service runs Ardusub with hard-coded arguments.

### Expected or desired behaviour

The user should be able to somehow provide their own arguments to the ArduPilot executable. This would allow the user to define parameters such as the GPS starting location (`--home`), simulation model (`--model`), SITL framerate (`--rate`), and simulator ports.

On the backend, I think it would make most sense to store these parameters in the `settings.json` (`--model` is already stored here). Other backend changes would include:

- Detecting and communicating ArduPilot crashes. Part of what made #3419 tricky to debug was that it was not readily apparent that ArduPilot had failed to launch. If users will be providing their own arguments, BlueOS should let them know if their process failed and why.
- Reloading settings in `ardupilot_manager.py` after each change to the settings or before restarting the Ardupilot process
- API endpoint for modifying Ardupilot arguments
- Storage for default arguments

I'd also make a method for launching ArduPilot instead of the individual `popen`s in the `start_sitl` and `start_linux_board` methods. I haven't confirmed this, but I think the current implementation creates a bit of a visual bug when using SITL firmware. The serial port configuration shows, but the configuration isn't ever included in the `popen` call in `start_sitl`. I think this means the user can modify the serial port configuration, but it won't do anything.

The frontend could be handled in a few different ways:
1. The simplest way would be to provide no frontend and have the user just mutate `settings.json` with the file explorer. This works, though is highly inelegant. If this route is taken, it should be documented in-app and in the [Advanced Usage](https://blueos.cloud/docs/stable/usage/advanced/) guide.
2. A more elegant solution would be to provide users a "build your own dictionary" interface, where they can provide the names and values of the arguments they would like to provide. Default arguments should show up as pre-populated fields.


3. The most user friendly (though likely hardest to maintain and least flexible development-wise) solution would be to provide a validated input field for every single argument. This would be very difficult to maintain for firmware versions with different options, and seems like overkill for something that will likely be a "Pirate Mode" feature.

I'll be developing at least the backend of this next week, as I need it for my simulation architecture. No pressure to pull this if it's considered too niche for the main application. If anyone has suggestions or amendments I will gladly take them into account.

### Prerequisites

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

Start with ardupilot_manager.py, especially start_sitl and start_linux_board, and inspect how settings.json is used. Review the proposed API endpoint and the Advanced Usage guide before choosing among the frontend approaches. Done means users can provide arguments, reload or persist settings, and understand launch failures and configuration behavior.

Written by the indexing model from the issue text.