New CMake structure and plugin-based blocks architecture

[diegoferigo]

New CMake structure

After the previous big refactorings (#56, #77, #115) the wb-toolbox became more modular and these modules have been kept as independent as possible.

After these changes to the C++ side, this PR split the components at the CMake level in the following components:

Component name	Description
Core	It contains core interfaces and classes such as Block, Signal, BlockInformation, Log
Mex	It contains the S-Function that generates the mex file and the implementation of BlockInformation for using block libraries with Simulink
Coder	Implementation of BlockInformation for using block libraries with Simulink Coder output
Library	It contains all the implementations of Block

Core, Mex and Coder represent the real machinery of the toolbox (whose targets are named just Toolbox* for the time being). They will represent the new project described in #83.

New plugin-based blocks architecture

Simulink

Until now the mex generated from the S-Function was dynamically linked to the analogous of the Library component. The split introduced a problem due to the factory machinery. Since Mex is standalone, it doesn't know any information about the library containing the wbt::Block objects to allocate (they can also be different libraries) and hence the factory function was an unresolved symbol in the S-Function itself.

This PR introduces a new plugin-based approach to tackle this problem. The S-Function running in Simulink uses dlopen in a plugin fashion to get the Block object, which must know the name of the library file that contains it. This information is stored in the Simulink Library (.slx file).

Simulink Coder (C++)

Instead, the Library component can be linked either dynamically or statically with Coder and a main function in order to use it as a standalone C++ application after the code has been generated by Simulink Coder.

cc @traversaro @DanielePucci @pattacini

[traversaro]

@diegoferigo ping me when the PR is ready for review.

[diegoferigo]

@traversaro It is already. I had the last minor edit in pipeline, just squashed it.

[diegoferigo]

Despite there is some ongoing work on a standalone version of sharedlibpp used for a multiplatform dlopen, I'm going to merge this PR that ships it within wb-toolbox.

We might consider in the future to use a submodule pointing to the new library.

Merging as soon as Travis passes again against the latest yarp:devel if you don't have any concern. cc @traversaro