DRAFT add queue and thread for processing mRunnables asynchronously

[mihbor]

I discovered some issues caused by long running service.js code. The problem seems to be the MDSManager is single-threaded. When one Minidapp's service.js is doing something for a long time, blocking the thread, messages aren't delivered to other minidapps and the MDS Hub stops functioning corretly as well. Here's what I observed happens when service.js is running for a long time:

• the Minidapp frontend stops receiving new messages when polling
• other minidapps stop receiving messages to the UI as well as into their service.js
• if you uninstall the Minidapp, the hub says its uninstalled but the service.js operation keeps running
• if you update the Minidapp, the hub says its updated but when you click on it, you get the old version
• if service.js is doing the long operation during initialization, then when you install the app and then click it in the Hub, it doesn't work, because the url is missing the UID, because it's only assigned after service.js has been initialized
• if service.js is doing the long operation during initialization, when minima starts, the Hub doesn't work at all because until that finishes

I can't see a simple fix for this. Ideally, I imagine each mRunnable should have its own queue of commands to process and a (small) pool of worker threads should be picking the mRunnables with non-empty queues and processing them asynchronously, while the MDSManager would only add new tasks to the queues.
A much simpler approach that fixes the worst issues of the hub itself not working correctly would be to have at least a single queue of pending tasks for all the mRunnables and one background thread to process them.

This PR is just a draft, a WIP, to show what the approach could be, to begin with. It's far from ideal but I tested it (on desktop) to fix the hub missbehaving at least, as a start.