Not sure if this is really needed though.

This is still very simple. Only really free memory, when all allocation
have been deallocated so we only need to keep track of the current
number of allocations.

Add basic GPU/CUDA integration as a shared library

See merge request acs/public/villas/VILLASfpga-code!9

Start splitting common parts (plugin, logging, memory, ...) into a separate library

See merge request acs/public/villas/VILLASfpga-code!8

Using CUDA, memory can be allocated on the GPU and shared to peers on
the PCIe bus such as the FPGA. Furthermore, the DMA on the GPU can also
be used to read and write to/from other memory on the PCIe bus, such as
BRAM on the FPGA.

It is probably too costly to do (and verify) it on every read
or write. Furthermore, the user knows better how to make a certain
memory available to the DMA.

In this case, VFIO cannot create DMA mappings.

This is used for translations that don't use VFIO which used to bridge
the PCIe address space by creating direct mappings from process VA to
the FPGA. When we want to communicate directly via PCIe without the
involvment of the CPU/VFIO, we need the proper translations that are
configured in the FPGA hardware.