Missing a trivial free at the end of the bpm_client
destructor

Some functions inside the respective open () calls can fail,
specifically _init () ones. So, we must destroy everything
allocated before that and exit.

Now we chack for the presence of the Makefile.
If not present, we generate it through autotools.

As we have changed all of our third-party repos
to the foreign folder, we must update them in the
top Makefile

Now, our PCIe driver resides on a different path

Now, the PCIe driver is located in foreign/pcie-driver

This folder now holds our subprojects and third-party code

We can choose whether or not  we want the compilation of DEV_MNGR.

Also, some conditional compilation is in pace, in which
we can choose what DEVIOs to compile.

This is a first stub for the RFFE DEVIO and will not work!

The dev_io_core.h is the generic dev_io include and should be
used in agnostic code. The dev_io.h include should specify
specific definitions.

This gives more meaning to the program and allow us
to create more dev_io's, such as the new RFFE dev_io,
in the near future.

In this way, we favor the reuse of the array structure by the libclient,
for instance.

This is not needed anymore, as the NULL field marks the end
of our arrays.

In this way, we avoid extra pointer access and unify the way we
check for our array bounds: always check for the NULL array element.
Also, the disp_op_end, which was used for marking the end of the array,
is not needed anymore and was, thus, removed.

As ML605 platform has only a single BPM, instead of two, we need fewer
definitions here.

We've changed the base address name and did not reflect these
changes for the ML605 platform.

Now, we must pass the array size of both parameters.

This adds safety, as we explicity enforce array bounds.

Although we check for more things here. That doesn't actually help
us against out-of-bounds exception and will probably cause a
segmentation fault if that occurs.

Final step to fix #48 github issue

Step number 3 on fixing github issue #48

Step number 2 on fixing github issue #48

Step number 1 on fixing github issue #48

This is just for convenience of the SMIO environment.

Now, we can initialize the exported function descriptor by means
of a different structure. This is necessary to keep function
description and function pointers separate (next commits).

This starts to solve github issue #48.

As we are using the new disp_op_insert_all () we don't
need an extra table with the opcodes.

This fixes #53 github issue