It seems that xcomp can't manage to reliably compile core+ units.
Let's limit the role of xcomp to z80c+icore.

I'm getting a little desperate here. I'll revisit the link.fs approach
with a new idea I had...

Replace its usages with direct RAM+ offsets. The (sysv) mechanism was
incompatible with cross-compilation of a full interpreter.

It's not needed anymore now that the boot binary is built in one pass.

... instead of building boot.fs, and then z80c.fs/icore.fs in separate
passes. This strengten xcomp by making it support 2 completely separate
dicts (that is, the X dict is *not* connected to the system dict. The chain
now stops at EXIT def in boot.fs).

We can now cross-compile core.fs.

It was a dead end. my new tentative solution is xcomp.

Memory mapping is a dead end too, solution has to be at a higher
level. xcomp is my new approach.

This makes IMMEDIATE affected by memory mappings.

This way, it can be affected by memory mappers.

How did this ever work?

This was a dead end.

Why didn't I think of adding it before?

Why did I ever think that using CM was a good idea? any comparison
with numbers more than 0x8000 apart would be wrong...

Not quite functional yet, but works in toy situations. The goal is to
concatenate RC2014's bootstrapped dict to the boot binary.

It copied one too much.

It simply didn't work before, except for =.

`xxd' is not available on all systems, and on others does not support
the `-i' flag. Since bin2c.sh relied on a tool that I can't seem to find
a compatible version of, I have included a simple, portable replacement in C.

Usage remains the same:
bin2c ARRAYNAME < inputfile > outputfile.

This change is also reflected in emul/Makefile.

Simpler code, more predictable output.