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.

quick fixes found by the test system (which we can later request to merge
upstream)

add math.h header that we missed from one of the previous Pd Vanilla port commits
fix two format specifiers that were the wrong type
commit 06cbbf40ef0f89cfb17462f66eaf86da172a3033

commit 4ec6b6437261342b979f5f818d33f5141cb91386

(bug report https://sourceforge.net/p/pure-data/bugs/158/)
commit e454201dc1dfd773813dc9274abb1786f965af06

and stopped while spooling to disk)
https://sourceforge.net/p/pure-data/bugs/1077/
commit 060a5d945c6fb70b4d82040665b53a4abc6beb5c

tabread4~ needs at least 4 samples to interpolate;
this patch adds guards in order to not access out-of-bound indices in the table,
in case the table is smaller than 4 samples.
commit e667894370ec22bc1d1d844443d90f1a76adc03e

if the entire soundfile fits into the fifo, then [readsf~] will start
to loop the file, since the 'drained' test in d_soundfile.c:1937 does
not trigger.
the fix is to properly set the fifohead (in the read thread) to the new
position, even if the read() returned '0' (indicating EOF)

commit 057cb3ee6cc58597a1b74a00a7880c2cfd0a466a

tabread4~ needs at least 4 samples to interpolate;
this patch adds guards in order to not access out-of-bound indices in the table,
in case the table is smaller than 4 samples.

commit e667894370ec22bc1d1d844443d90f1a76adc03e

commit 420bd1fffa0336650309d4c158c6dd208d993310

port from Pd Vanilla: aiff (and maybe wav) file reading bugfix: odd-sized chunks are padded up to even number of bytes
commit a567e4398d14901840f24ac82ecfc79306e22903