This HALT bit was unused. So, we cahnged its meaning
to "print without prefix/headers", which is useful
for more complex printing, like SDB records.

For BE devices we can use the new SDB initialization.
However, FE devices do not have SDb implemented.
So, they rely on the static spawning.

These addresses are not needed anymore,
as they are already read from SDB and passed
to the SMIO as part of the base address.

This is just to ensure that the FMC250M SMIO will be
initialized. This is temporary until we figure it out
a way to do this properly: signaling that the SMIO
has finished initializing.

All of the SMIOs are now spawned by the SDB
engine. So, if we want to avoid spawning a
known module or something else, we must
create a way to do so. Like a config file
supporting blacklisted modules.

It was missing the SDB prefix address (got from
LLIO) and the "first" offset from the current SDB device.

Now, these addresses are read from SDB

This will be used as a prefix address for read/writing
to the SDB memory space. If an endpoint does not implement
or support SDB, it should set SDB address to 0x0.

We need to pass the actual inst_id that was used to
generate the SMIO identifier. Previously, we were
passing the incorrect value.

We could have generated an invalid key. So, we
must check this before proceeding with spawning
an SMIO with this key.

This adds a first try to the long-waited
functionality of spawning the SMIOs based
entirely on the SDB parsing.

Now, we create/remove the SDBFS on devio_new ()
and devio_destroy ()

For now, only LLIO with PCIe endpoints are
supported.

As we have changed the data width, we must
print it differently.

The range of commits from lnls-dig/bpm-gw@f7d6e831fd
to lnls-dig/bpm-gw@dc8e06241f changed the acquisition
map. So, we changed it here.

The types size_t, ssize_t, uint64_t must have
portable specific types, such as: zu, zd and PRIx64.

This IDs are located on the specific
RFFE SMIO called sm_io_rffe_codes.h

Now, we can start/stop bpm-sw-fe and bpm-sw-be
instances independently or using just the
bpm-sw instance

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.

As the RFFE hardware changed, we did not update
the bpm-sw communication with it. Many variables
have ceased to exist and other have been included.