Completely redesigned module import/loading subsystem

EEL functions load() and compile() in builtin.eel replace
the respective native calls. The C API call eel_load()
simply wraps eelbil.load().

load() doesn't actually load anything. It just iterates over
$.module_loaders (an array of functions) until one of them
returns a module. (Of course, $.loaders can be manipulated by
scripts in order to add, remove or reorder module loaders!)

Added $.injected_modules table, where host applications (or
scripts, for that matter) can add loader/initializer functions
for specific modules. (This is how host applications inject
their compiled-in native modules, and that's how eelbox is
currently implemented.) $.injected_modules is implemented by
the __load_injected_module() module loader.

Added $.path_modules array that load() (by default, via
__load_via_path_modules()) uses to find modules in the file
system.

Removed eel_import(). The 'import' directive uses eel_load()
instead. (The only remaining difference from eel_load() was
that the latter wouldn't consider already loaded shared
modules, but if we want to be that specific, we're probably
better off bypassing .)

Removed the 'include' directive. The implementation relied
on the module loading subsystem, which wasn't appropriate
in the first place. And, 'include' is probably a bad idea
in a high level language with proper import modules anyway!

Removed eel_save() and the '-o' switch. Never implemented
anyway, and the API will probably be quite different if/when
it is. Binary modules are a bad idea anyway, at this stage!

builtin.eel now actually has the module name "builtin", as
one would expect, and the native part is "builtin_c".

math.eel, dir.eel and dsp.eel tests renamed *test.eel,
because now we can't escape the naming conflict with the
respective native modules they're testing...! (Oops.)

Fixed a bug where C functions were assumed not to cause VM
heap reallocations, which is incorrect, as C can call EEL
and vice versa recursively.

REMAINING ISSUES: Segfaults related to limbo lists. They
appear to have something to do with XRETURN and corrupt
return values.
Extra checks and descriptive exception strings in builtin.load()

load() now checks that it actually gets modules from the loaders,
and throws an exception if it gets anything else. It also throws
a message instead of XMODULELOAD.

Also cleaned out the ifdef'ed out old module loading code.
Temporary fix for the load() segfault issue

I think I've figured out what's causing it: Some problem with RETX*
into native functions.

EEL implements exception handling by compiling 'try' and 'except'
blocks as functions, which makes it easy to cleanly exit them at
any point, and that's also how the 'retry' feature could be
implemented so trivially.

However, when executing a 'return' statement inside an exception
block, we can't use the RETURN instruction, as that would just leave
the exception block. So, we throw a special exception using one of
the RETX* instructions.

Now, somewhere around here is where the problem is; that mechanism
is somehow failing to handle the differences between native functions
and EEL functions. If we return directly to a C function (which is
the case when builtin.load() returns to eel_load() in e_module.c),
something goes wrong and we get corrupt return values.

This "fix" simply wraps load() with a trivial EEL function, so that
we avoid the RETX* into native code for now.
Minor cleanup

Removed duplicate builtin.c generation in cfg-all.

Removed debug printouts in builtin.eel compile().

Disabled DBGZ (Print all messages instantly) in DEBUG builds.

Removed redundant characters from the eel_callnf() in eel_load().