Plugin ABI compatibility

[pogmat]

@luca-heltai
With PR 52 MPI is initialized once in the plugin using it. Coral itself is transparent.
Coral has been provided with a MPI aware logging thought it does not link with MPI library in order not to create conflicts.
Logger is extended via plugin interface to the plugin itself so also from inside the plugin one can log.

Discussion Points
Plugins have C interface. This may leads to think that coral + plugin are ABI independent. They are not, since when we register type plugin and coral shared a state which requires: 1) coral to be a shared library CORAL_BUILD_SHARED_CORE=ON and 2) the ABI of the compiler used to compile plugin and coral be compatible.

1. On linux seesm to work even if che coral lib is stati, but I think is extremely fragile, and not portable. I propose to remove and to enforce coral to be build as shared library
2. Since ABI compatibility is aready a requirement, we do not add any constraint if we pass from plugin to coral some handle (void*) to some C++ object and then reinterpret cast. It may be useful.