## Description
In order to ensure that reentrant calls can be made asynchronously (crucial for performance, especially if e.g. someone tries to Map() from inside the executor), each reentrant call will need to write all its output to stdout before another reentrant call starts writing its output. The flow will be
```
procedure reentrantCall:
acquire mutex
writeToStdout('start reentrant call')
writeToStdout({ Z1K1: 'Z7', Z7K1: ...})
writeToStdout('end reentrant call')
release mutex
end procedure
```
As a consequence of this, other writes to stdout must also be protected, since they might be happening concurrently with a reentrant call. For example, writing a debug log will look similar to the above:
```
procedure debugLog(logString):
acquire mutex
writeToStdout('start debug log')
writeToStdout(logString)
writeToStdout('end debug log')
release mutex
end procedure
```
Similarly, when the executor interface writes to the executor's stdin, the interface's `stdin` should be similarly mutex-locked.
Also, each reentrant call needs a unique ID to ensure that the results from the orchestrator are routed back to the correct async calls in the executor.
**Desired behavior/Acceptance criteria (returned value, expected error, performance expectations, etc.)**
* writes to stdout (in executors) are mutex-protected
* writes to stdin (in executor interfaces) are mutex-protected
* reentrant calls are assigned unique IDs that are propagated among the executor, evaluator, and orchestrator
---
## Completion checklist
* [ ] Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Back-end_Task/Bug_completion_checklist