improve locking in project handler

Task description

for the dot net interface locks are added as the garbage collector calls the destroy method from another thread.

with the changes in PR #342 the number of locks are way too many. But setting the lock on a higher level will set the lock more times and is often not necessary.

There are a few ways to solve this:

1. do not allow calling the project handler from different threads ; then the dot net wrapper has to handle it
2. move the locks to another location in the project handler ; see PR #342 for that location.
3. make the locking optional, then calling it too often only influences applications that actually need this locking.
4. use Concurrent Containers from Boost, see: https://www.boost.org/doc/libs/latest/libs/unordered/doc/html/unordered/concurrent.html
5. split up projectHandler.cpp and make a class for each type, e.g. StochastHandler, HistogramValueHandler, etc.. These classes have functionality in common, such as the code where the lock is required, which will be programmed only once. These classes are templated and all derive from a base class.

Additional context

No response

Start by reviewing projectHandler.cpp and PR #342 to understand where the current locks were added for the .NET interface and garbage-collector destroy calls. Compare the listed approaches and establish one locking strategy that preserves cross-thread safety without excessive locking; done means the chosen design is implemented and its thread-safety tradeoffs are documented.