Create separate maverick-only -api instance by default

[fnoop]

Thoughts from gitter:

Here’s a question/thought We run separate -api instances for each vehicle. But you don’t need multiple separate -api instances for maverick. Should we run a separate known instance just for maverick? It would be unusual but you don’t necessarily need to run a vehicle proxy/ros/-api set of instances on any CC, and in that case you then wouldn’t have access to maverick config/control Also if you were connected to say sitl -api on a dev box and stop it or it crashes for any reason (like it loses mavlink or mavros, or something goes wrong in those modules), you lose all control over the rest of the system It’s all starting to get a bit convoluted with lots of services running everywhere, but maybe we should have a single -api to control the system that is always running?

[fnoop]

@SamuelDudley I've created a separate config template for a system/maverick-only api instance that is created by default and put in the 'Web Services' group. It contains the config:

# List of modules to allow loading. Takes precedence over deny list
module_allow_list = []

# List of modules to deny loading
module_deny_list = ["mavros"]

Is this a sensible module config, or should it just allow a specific module?

I'm assuming that excluding the mavros module in the vehicle -api config would be useless, so we might as well disable the vehicle api instances until they're ready to do something? Or do you think it's viable to get basic mavlink stuff working in -api for a 1.2 release? Even just basic parameter editing and vehicle setup?

[fnoop]

Turn off vehicle -api instances by default, as they won't be any use for now. Edit: Disabled by default

[fnoop]

Rename api@maverick to api@system. Edit: Renamed to system