Polished and improved SimulinkBlockInformation

[diegoferigo]

• All the calls to Simulink API have been moved to the private class.
• Since we support only 1D and 2D signals, the BlockInformation::get{In,Out}putPortWidth should work only for 1D signals, analogously to the BlockInformation::get{In,Out}putPortMatrixSize that works only for 2D signals. I'm open to change the names of the method of the interface is the current ones are not clear enough.
• Getting Input / Output signals from the blocks should be safer now, the methods have been refactored and the checks now cover more cases.

I want to change the following methods in the BlockInformation interface:

virtual blockfactory::core::InputSignalPtr
    getInputPortSignal(const PortIndex idx, const VectorSize size = -1) const = 0;
virtual blockfactory::core::OutputSignalPtr
    getOutputPortSignal(const PortIndex idx, const VectorSize size = -1) const = 0;

and remove the size parameter. However, since this will affect also the SimulinkCoder implementation, I will open a new PR with also the rationale about it.

[diegoferigo]

Thanks @traversaro, feel free to send it to me if you find your comment by chance. Usually I never split the Impl class from the main one, if it happens often it means that it might be worth to create another class standing on its own (and I mean not being the private of another). In this case I don't see any possibility of code reuse of this small wrapper around the Simulink APIs, and I preferred to improve the readability of the SimulinkBlockInformation class by moving them out entirely, providing a sort of isolation.

[traversaro]

Thanks @traversaro, feel free to send it to me if you find your comment by chance. Usually I never split the Impl class from the main one, if it happens often it means that it might be worth to create another class standing on its own (and I mean not being the private of another).

Yes, my comment was basically this. In particular, in the past we had maintainability problem once logic was split between the actual class and the pimpl class (in the sense: if I had new logic to add, I add it in the main class or in the pimpl?), for this reason I always recommend to just put members in the pimpl, but in this case it make sense. if I would probably call the resulting class in a different way, even if it is just a private class, for example "SimulinkBlockInformationHelper", to make clear that is not a classical pimpl, but this are just details.

[diegoferigo]

Thanks for the feedback. For the time being let's merge this PR as it is since changing the class name would touch too many parts of file and it would be worth having a separate PR.