Rework network backend

We need to support some changes to make BlueOS more friendly with different network connections, and better for the user to manage them.
- [ ] (1) Allow disabling network interfaces https://github.com/bluerobotics/BlueOS/issues/1061
- Right now it's not possible for the user to disable a network interface, this is helpful to avoid using high cost network connection like cellphone or satellite links. This is a current problem when dealing with BlueBoat. Where the user can use a cellphone or a satellite link where wifi is still available. This is also a palliative solution for bigger problems, as the following items.
2. [ ] (2) Deal with with metered interfaces.
- This is a more friendly solution compared to (1), but also something that we need to implement. The idea is to have a metered interface where it should not be used when another interface not configured as metered is available. So, if you have a satellite link but you are connecting at your home wifi at the same time, the system should avoid using the metered connection, or even disabling it by default. It may be hard to implement this with (3).
3. [ ] (3) Use basesteam network for communication while a metered connection is available.
- When using BlueBoat, the vehicle be may connected though the base station and through a metered connection, as the computer that is communicating with it. We should use the base station interface when the user is connected with it. We may shift the solution to the user computer, where he should disable his internet connection while the base station is in use.
4. [ ] (4) Use high latency mavlink messages though metered connections
- [MAVLink high latency messages](https://mavlink.io/zh/services/high_latency.html) should be used in metered connections, avoiding high bills for the users that pay per bytes.
5. [ ] (5) We should allow the user to disable ipv6
6. [x] (6) Add support to NetworkManager
7. [ ] (7) Merge wifi manager and cable-guy in a single service
8. [ ] (8) We should not remove current features
9. [x] (9) We should be board/os agnostic
10. [x] (10) It should maintain our current API versioning system