Add support for action-calls-on-interaction from read-only input widgets

This came to my mind after reading [this discussion](https://discuss.bluerobotics.com/t/relays-on-navigator/15823/13?u=rafael.lehmkuhl).

The idea is: the user has a variable that is read-only (e.g.: a value coming from the MAVLink stream), like an arm state (boolean), and it creates an input widget of Switch type to show this state. As of now, the user interacting with this switch will cause nothing (or wrongly toggle the switch state till the updated arm state comes from the vehicle), but wouldn't it make sense for the user to actually be able to arm/disarm the vehicle by clicking this switch?

Today the user can kind of do that in a very convoluted way, by creating a middle-man variable with the desired state, assigning that to the input widget, creating an action linked to that variable to send new states of it to the action and creating a javascript action that updates the value of the middle-man one based on the value of the actual variable, with some proper delay. Yeah, I feel tired just from writing it.

This could be done in a much more fashioned way by adding a forms to the input widget configuration panel that allows the user to select the variable to which the input widget should be linked (e.g.: MAVLink/arm), the necessary configs for the action and the action field that should receive the new value when the input widget is interacted with (e.g.: the first parameter field in a MAVLink Action for arming). Under the hood we would simply create the Action, the middle-man DataLakeVariable and the ActionLink.

A much simpler alternative that could allow for easier integration (and will be needed for this more complex implementation anyway) is to simply allow an Input widget to:

1. Show the value of a data-lake variable
2. When interacted with, send the new value to a different data-lake variable, and not the one its showing the value of
3. Enter a "loading" state after interacted with, and this loading state is finished when the value of the "show" variable changes and/or after some amount of time (configurable by the user)

Besides the arm/disarm, that could also be used for things like motor throttle, depth, altitude, velocity, zoom, focus. Thinking more about it, this would be a hell of a feature.

Start by locating the input widget configuration panel and the data-lake variable, Action, and ActionLink flows described in the issue. Compare the simpler show/send/loading behavior with the more involved automatic resource creation proposal. Done would require an agreed scope, configuration model, interaction behavior, and tests for the selected approach.

Written by the indexing model from the issue text.