This causes an assertion error as the zactor
infrastructure needs the PIPE after the thread exits.

This fixes #116 github issue.

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 will allow DEVIO clients to register SMIOs
by sending messages to its pipe.

This pipe will be used to allow other SMIOs to
register new SMIOs

It's better to first attach the SMIO to its
parent (its DEVIO handler) and then initialize
the SMIO.

The SMIO might need something from the
DEVIO.

This, together with commits from c171576c
to bbe05bf6 fixes #115 github issue

In this way, we reduce code repetition and
maintenance becomes easier

In this way, we reduce code repetition and
maintenance becomes easier

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.

Now, if EPICS IOCs are started with systemd
they have a dependency with bpm-sw@.service

Removing the socket handler on *_cfg handle was wrong
as the devio_destroy_smio () already calls
devio_destroy_actor (), which, in turn, removes
the socket from the reader.

Also, as we expect only a single message on the
handler, it`s safer and cleaner to not poll the socket
until there is no message.

If an SMIO fails for some reason, continue to spawn
the other ones.