This reverts commit d47295f5.

This reverts commit 3964dea2.

This reverts commit 0fdcd2a4.

Conflicts:
	abstractions/Makefile

This reverts commit 86dae341.

make [declare -lib] handle absolute paths (and namespace-prefixed paths) consistent with object boxes

* the original namespace-collision checker only worked for abstractions
* trying a new namespace-collision checker revealed about 80 new clashes.
  Since there are so many it's probably too disruptive to remove them.
* probably need to revert the namespace clash abstraction removals

I don't see any use of the namespace prefix in the repo (like
la-kitchen/amplitude_n). So while this has the potential to break
some patches in the wild, it appears most people have been using
either unprefixed names or the more popular mapping library prefix.

If this ends up breaking a bunch of stuff we can always revert it.

This will allow legacy externals like iemmatrix and zexy to properly load
aliases the first time when the user instantiates an object with
[namespace_prefix/alias_name]

This becomes relevant when there are kludge classes that essentially just
"#include" the original C file of a class and add an alias_setup function
which just calls the original setup routine. (For example, see iemmatrix.)
However, such an approach still calls class_new with the original class name.
Thus "namespace_prefix/classname" gets added to the pd_objectcreator
methodspace, but "namespace_prefix/alias_name"-- which is what we want--
does not. This results in a series of 1000 recursive calls into
pd_objectmaker's new_anything method. (I.e., sys_load_lib finds the
"namespace_prefix/classname" is already loaded, new_anything_sends a
typedmess to pd_objectmaker's new_anything method, which calls
sys_load_lib, etc.)

To prevent this, we just make sure to add "namespace_prefix/alias" by
adding the relevant lines to class_addcreator. This should really be
happening anyway-- since internal classes don't have a class_loadsym
they aren't affected, and externals with aliases won't work with
namespace prefix without this.

It appears iem16 is supposed to be built as a single binary. Unfortunately
Pd-extended broke these up into separate binaries without setting up a
sensible cross-platform shared library.

Thus Pd-extended had creation-order problems where, for example, the tab16
classes depended on a table16 to already exist so that the relevant symbols
could resolve properly.

We have no way of knowing how people were using these classes in the wild with
Pd-extended. To support old Pd-extended patches we just use copy/pasta for a
few functions so that any of the classes can get their objects instantiated
without depending on any of the other classes already existing.