Now, instead of spawning a DEVIO BE application
and that application, in turn, spawn the DEVIO FE,
we are using a more modular approach in that each
DEVIO BE or DEVIO FE spawns a single application.

We will rely on the system integration (such as
systemd) to take care of our dependencies for us.

Github commit lnls-dig/bpm-gw@d952234374 changed it.
So we update it here.

Added "_BASE" to name address, for consistency
with existing names.

This is very useful on setting/getting registers in
modules that have multiple channels with the same
register definitions.

This way avoids users needing to know how this
is implemented internally and, obviously, decreases
the chances of error.

In this way, we can standardize how the
functions are called and handled.

This is necessary as lnls-dig/bpm-gw@6a78088ab1
and lnls-dig/bpm-gw@950b4b2d18

In this way we can guarantee that these functions
will be thread-safe even if other SMIOs calls them.

The previous implementation was not thread-safe.

We should replace this functions by sending a
message to the DEVIO instance through the
PIPE management.

This opens new possibilities for chaining SMIOs.
For instance, the FMC_250M SMIO can register 2
more SMIOs: FMC_ADC_COMMON and FMC_ACTIVE_CLK

This was include in commits from lnls-bpm/bpm-gw@09f35bd8f7 to
lnls-bpm/bpm-gw@3c537b769f

The FPGA gateware was changed to uniformize
the WB register map for the FMC ACTIVE part.

We are now using a reactor API, zloop, which is better
coded and more standard than a custom poller loop.

Instead of using the index of the smio_mod_dispatch table,
which is weak and error prone, we use a handler pointer instead.

The MSB of the ISLA216P transaction must be
R/W bit followed by Length specification,
Register address and data (for write transactions)

If we are using SPI in bidir mode, the character
length should be copied to the 7 LSB of
"SPI_PROTO_REG_CFG_BIDIR" and not
"SPI_PROTO_REG_CTRL"

This is the correct place for them as this files
could be used for other modules.

This is the correct place for them as this files
could be used for other modules.

With this, we can specify if we want to use a
bidirectional (three-mode) SPI or the regular one.

This, of course, relies on hardware support.