I'm planning on adding other subfolders. 8086 for example...

The C VM now runs the show.

XPACKed source needing to be kept in bootstrap bin didn't make
much sense. With the removal of stripfc, it makes more sense to keep
the compiled form of stage 1 in repository as a bootstrap binary.

Also, rename it to forth.bin.

Less noisy this way

It's not used

This requires us to significantly adjust our build process, which
now has 3 stages.

My approach with RS was slightly wrong: RS' TOP was always containing current
IP. It worked, but it was problematic when came the time to introduce
RS-modifying words: it's impossible to modify RS in a word without immediately
messing your flow.

Therefore, what used to be RS' TOS has to be a variable that isn't changed
midway by RS-modifying words. I guess that's why RS is called *return* stack...

Big one.

This allows us to write higher order words directly in Forth, which is much
more convenient than writing post-immediate (see "NOT" structure in diff if
you want to see what I mean) structures in ASM.

These structures can then be written to ROM (rather than loaded in RAM for
definitions loaded at run-time).

That's quite a bit of tooling that was added, 2 compilations stages, but I
think it's well worth it.

Also, add the new `bshell` emulated tool. BASIC is on its way to replace the
shell.

That's my mega-commit you've all been waiting for.

The code for the shell share more routines with userspace apps than with kernel
units, because, well, its behavior is that of a userspace app, not a device
driver.

This created a weird situation with libraries and jump tables. Some routine
belonging to the `kernel/` directory felt weird there.

And then comes `apps/basic`, which will likely share even more code with the
shell. I was seeing myself creating huge jump tables to reuse code from the
shell. It didn't feel right.

Moreover, we'll probably want basic-like apps to optionnally replace the shell.

So here I am with this huge change in the project structure. I didn't test all
recipes on hardware yet, I will do later. I might have broken some...

But now, the structure feels better and the line between what belongs to
`kernel` and what belongs to `apps` feels clearer.

Let's see where it will lead us...

This way, we can compile apps from within the shell that run on the
shell.

What used to be `tools/emul/user.h` was in fact specific to zasm, so I
moved it there.

To avoid name confusion, I renamed what used to be kernel.h and user.h
to kernel-bin.h and user-bin.h.

Will be much much easier to tests new core routines without having to
re-create their context first.

Also, extract parse.asm from core.asm

On build, pack `parts/z80` into a CFS and embed it into the emulated
zasm executable as an fsdev. This will allow for the upcoming include
directive to have something to go to.

For now, this is useless except for inflating the emulated zasm's size.

With the help of the newly-introduced cfspack tool, we can mount a
filesystem in our emulated shell and play around. Read-only for now.
Unpacking incoming.