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.

revert to using a single way for finding the libdir, as my assessment of the OSX bug turned out to be wrong

This reverts commit b72d9703.