Introduce Threaded Executions to the Runtime Server Instrument

[kustosz]

Summary

The way the runtime server is implemented right now, we have no control over running Enso programs and execution is effectively blocking the rest of API.

Value

1. We can control execution better in the future (e.g. abort / restart it on-demand).
2. We can keep the servers active even if a long-running computation is executing.

Specification

• Implement a message queue with worker threads (based on Executor.submit()). Jobs should be executed asynchronously.
• Implement Context#createThread(...) that dispatches to TruffleLanguage.Env#createThread(...) instead of the standard Java thread primitives.
• Refactor current handler to submit commands to the message queue.
• Create a flow chart that describes the priorities and succession rules of the various incoming messages (should become part of the language docs). Messages in the handler can generate multiple jobs. In runtime docs, and these should account that concurrent modifications to the Context should not happen. (Marcin)
• Determine and document the reordering rules for the generated jobs. In runtime docs.
• Implement the reordering rules as specified.
• Implement preemptive interruption of threads where necessary. This must use Thread.interrupt() (the java primitive).
• Update the spec to reflect any protocol changes.

Acceptance Criteria & Test Cases

• User code executes in threads asynchronously so as to not block or time out the language server.
• The functionality is well documented and tested.