initial implementation of spawnable forth tasks

[hawkw]

This branch adds an initial working implementation of a spawn builtin
word for Forth tasks. The spawn word takes the address of a word in
the Forth VM's dictionary, and spawns a new child VM that will begin
executing that word.

The child task is created with a bbqueue bi-directional channel for
its input and output streams, although these are currently not used yet.
Subsequent changes will probably need to give parent tasks a way to
actually send inputs/outputs to their children, if that's something we
want to do. Currently, though, we can basically only see that the child
task is running by checking the kernel logs for evidence of its
activity, or by having it open serial mux ports and communcate on them.

Potential Future Work

In follow-up branches, we should probably add some new builtins:

• a way for tasks to sleep (ideally, using the maitake timer
  wheel!)
• a way for parents to wait for their children to complete (the
  spawned child task's JoinHandle)
• a way for parents to kill their children
• a way for tasks to explicitly yield to the scheduler
  (maitake::future::yield_now())
• a way for tasks to write to each other's unputs and outputs.

Some Notes

In order to make this work, I had to increase the kernel heap size in
Melpomene significantly. One consequence of the async allocator is that
if a task is trying to make an allocation that there's no space in the
heap for, and no other tasks are going to free memory that will make
that allocation possible, the child task just hangs forever and it's not
obvious why. We may want to consider adding debug logging to the
allocator so that we know when a task can't allocate because the heap is
full. Also, we may want to consider making futures run in
Kernel::initialize (rather than Kernel::spawn) set some kind of flag
that makes the allocator panic on OOMs instead of waiting for heap
capacity. Since the initialize futures run before the OS is actually
ready to run user input, and most tasks started in initialize are
parts of the OS that will run for as long as the system is up (and
therefore probably won't release most of their allocations), we may want
OOMs to be fatal while starting up, and only make user task
allocations wait for heap capacity. Just a thought.

[netlify]

✅ Deploy Preview for merry-scone-cc7a60 ready!

Name	Link
🔨 Latest commit	eb800e7
🔍 Latest deploy log	https://app.netlify.com/sites/merry-scone-cc7a60/deploys/647b7d9909c39a0008915281
😎 Deploy Preview	https://deploy-preview-53--merry-scone-cc7a60.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[jamesmunns]

Looks good! I think there are definitely some open questions, but I figure we'll stand a better chance at answering them after playing with the system for a while.