Changed PluginFactoryBase::*findPMaker to return void*

The functions *findPMaker used to return an iterator to an internal structure of PluginFactoryBase. This exposed the implementation too much (since it will be changed next). However, the calling routine didn’t really care about the iterator and always just pull one particular value from the iterator. The functions now returns that one value.
Member data m_plugins was moved from protected to private
Use mutex to protect Plugin system

dlopen is not thread safe and therefore must be protected from simultaneous access. Given that this system is used outside of cmsRun using a mutex was considered the best option for serialization. Given the fact that the plugin system shouldn’t be called in a time critical manner, it was easiest to protect the member data also using a mutex. If this causes a performance problem, we can review it and try to use a tbb thread-safe container instead.
Switched PluginManager to use a recursive mutex to protect the dlopen

Testing showed that actual configurations were locking up do to the mutex already being held. The only way that could actually happen is if during a shared library load another plugin is requested to be loaded. Switching to a recursive mutex will avoid such problems.
Merge pull request #1083 from Dr15Jones/recursiveMutexForPluginManager

Multithreaded framework -- Recursive mutex for PluginManager