This is another stop-gap due to the GUI interface not protecting against
messages that arrive before the GUI windows has finished loading.

The code for $@ depends on reading a_w.w_symbol values, but the other
A_DOLLAR branch (i.e., for $1 - $n) depend on reading a_w.w_index.

So for the conditional at the top of binbuf_eval, this means that any
normal A_DOLLAR that has its a_w.w_index set is actually trying to read
a_w.w_symbol. On a 64-bit arch with certain compilers, this will result
in a read of uninitalized data in the padding of the part of w_symbol
that exceeds the sizeof(int).

The workaround here is to define a sentinel value DOLLARALL to a negative
int unlikely to ever be used in real A_DOLLAR values. We then use DOLLARALL
to mean the "@" in "$@" so we can create a special branch for it in the
parser.

One consequence-- we probably need to add a special case error when
this value is out of range. So rather than confusing the user with the
mysterious negative value of DOLLARALL we print "$@" for them. (Currently,
the only place I can see this happening is when "$@" is used as the
target for a Pd message.)

It appears int and t_int were freely mixed in this external, causing a size
discrepancy that can result in a buffer overflow. Since t_int is supposed to
be function pointer-sized container, it's unclear why that would be used here.
This commit changes all t_int use to int.

If t_int was really meant here for some reason then we can go in the other
direction.

matters. :(

for aliased zexy classes from externals/Makefile

required by the Makefile)

the main loader

hexloader external (which will consequently be removed). The interface
is:
1. If any characters that were illegal in a C function name were in the
   given object name, we get a "hexmunged" symbol where each illegal
   character is replaced with a "0x%c" where "%c" is the hex representation
   of that illegal character.
2. If we have a "hexmunged" symbol, we search for a file by the newly munged
   name. Currently this is search in addition to the normal paths-- it could
   probably be searched instead of it but I'm not completely sure if there
   are any edge cases that would be affected by that.
3. If the file is found, the loader searches for a setup routine named
   "setup_hexmungedSymbol". If it's a tilde object, it searches for
   "setup_hexmungedSymbol_tilde". (Note: normal external libs search for
   "normalLibname_setup".)

Caveat: a lot of the obviously ad-hoc code for handling this cases in the
        external libraries just uses an "#include" directive for the entire
        C file of the original object. E.g., mtx_0x2a.c just does
        #include "../src/mtx_mul.c" with an extra setup routine that just
        calls the original one.

        So if a patch or running instance has both the [mtx_*] _and_ the
        [mtx_mul] objects, two separate libraries which essentially the
        same code and "setup" symbol will get loaded. The same is true
        for the original hexloader. I haven't had time to study the loaders
        on all Pd's platforms to figure out what the side-effects are of
        this approach

This reverts commit ddfbb4f5.