Refactor of MAVLink controllers to enhance protocol modularization

[angel-ayala]

The controllers for MAVLink messages dispatch and process now seems outdated and requires to update its architecture aiming to unify all definitions related to messages in a self-contained unit, as possible.
Our last issue introducing such idea is #61, nevertheless different PR and issues were updating the MAVLink service logic, but focusing on isolated aspects not looking to improve it as a package. All the issues addressing changes in controllers package identified so far are #7 , #8 , #26 , #43 , #45 and #61, and here I would like to summarize the things that can be improved.

When the application development started and controllers package architecture was defined there was under heavy development, and now with a more stable architecture in the interfacing logic, is being necessary to update this service logic, and the SDK logic in a future.
First of all, we need to review the mentioned messages to implement those that are required and still missing, such as the case of FLIGHT_INFORMATION.

This is the current mavlink package content without any discussed changes:

├ MAVLinkService    -> execution entry point
├ MAVLinkClient     -> transport
├ MAVLinkController -> internal logic
├ `controllers`     -> repository of extended logic
├ `messages`        -> parsing of message

The overall idea was to MAVLinkService handle MAVLinkClient init/shutdown and pass WenuLinkHandler as handler attribute to MAVLinkController (#45), which act as a central point for all other controllers such as NavigationController inside controllers. And recently (#43) , was added the messages package to translate MAVLinkMessage parameters from commands and request mainly, into meaningful attributes names.

Right now, there is no issue related, but it lacks of a suitable architecture since the message processing logic definition is split in controllers and messages and must be updated to have a unit definition on what to do, similar to commands, but considering two main situations, incoming messages that needs to perform certain procedures and outgoing messages that can be instantly sent or scheduled to be sent iteratively. Additionally, to further fully comply with the routing mechanism, a pre- and post-processing of messages is also required to first check if something must be done or skip such message, and to set proper routing data before send, respectively.

As suggestions, controllers can move to a registry-driven approach acting as entry point for specific microservice messages, being capable of auto-load its registry. In such way there should be a new dispatcher, scheduler, and registry classes to dynamically deals with actual unit definitions, keeping controllers simple, being used only as message registry point and hooks. Such changes will require to extend base abstract classes, that IController's update, there should also be a new IMessageHandler that will define the structure for the units definition. Hoping that the controller class will be reduced enough, the kotlin file can have the microservice name, for example MissionMicroservice.kt and comprise the controller and units definitions.