Patches missing in the rdt-next-snrkiwi-add-send+cmd-to-scriptfunction branch?

CC: @smits, @snrkiwi

What about those three patches which are not in the cleaned up rdt-next-snrkiwi-add-send+cmd-to-scriptfunction branch? They are not required to fix the master/slave state machine issues or for the new .cmd syntax but solve some other issues we observed during the last weeks and the work on top of rdt-next.

The blocking `FileDescriptorActivity::trigger()` method call is only a problem if the activity is triggered for more than 65536 times while one step is being executed. This could be a symptom of something else that went wrong and blocked the ExecutionEngine for too long, which has been fixed by the other patches in the meantime. If the component running with a FileDescriptorActivity is triggered frequently and its execution involves blocking calls or commands, then I would strongly recommend to use this patch as well.

The second patch fixes an OperationCaller's decision whether to call or send an operation directly depending on whether it would be executed by the same thread or not. This was kind of broken before in case of operation calls from slave to master components or vice-versa, where two ExecutionEngines share the same thread. In those cases the send() calls were enqueued and executed in the next cycle. With this patch, sending an operation that is owned by the master from the slave or vice-versa is executing the operation synchronously. I am still not sure if we really want this, as it somehow mixes the semantics of calling and sending. In my opinion, if the user sends an operation, it should always be executed in the next cycle even if the executor is the same thread. In this case we should only remove the `myengine != caller` check in `OperationCallerInterface::isSend()`.
Additionally, the patch changes the return of the MainThread as the default thread to SlaveActivities without an explicit master. @psoetens should review this before it would be merged.

The third patch fixes the missing `disableEvents()` call in `StateMachine::deactivate()` and adds a mutex lock to `StateMachine::activate()`.