prevent double-precision externals from crashing a single-precision Pd (and vice versa)

[umlaeute]

this implements a simple, API-compatible mechanism to prevent double-precision externals from being loaded into a single-precision Pd and vice versa, as proposed on the mailnglist and mentioned in #299

how it works

• single-precision (PD_FLOATTYPE==32) externals use class_new() to register new classes
• double-precision (PD_FLOATTYPE==64) externals use class_new64() to register new classes

if an external uses the wrong variant of class_new (e.g. class_new64() on a single-precision Pd host) will yield an error message and the class will not be registered (with class_new returning NULL).

API compatibility is kept by using a pre-processor define, so externals keep using class_new in their code, but it gets magically replaced with class_new64, if PD_FLOATTYPE==64.

ABI (binary) compatibility is retained for single-precision externals (since we still use class_new()), but not for double-precision externals.

this also adds some NULL-pointer checks to functions with a t_class* argument, since practically all externals do not check whether class_new returns NULL.

[umlaeute]

the first commit (by @lukexi) is slightly unrelated to double precision, but since double is also a lot about "64bit" I included it :-)

[umlaeute]

up to date with today's (0.49-0test0) master branch

[millerpuckette]

I think this can be done better by having 64-bit-float versions of Pd call xxx_setup64(). That way,
a single object file could have both 32 and 64 bit code.

[umlaeute]

the proposed way does allow single binaries to have both 32 and 64 bit code, as the external might still call class_new64() to register double-precision objects even when compiled with PDFLOATSIZE=32 (and vice-versa; although in the latter case it has to undefine the class_new override first. but that's pretty simple).

it also caters for libraries that do not use the xxx_setup function at all, but instead call the class_new() from _init(), __attribute__((constructor)) or a static C++-object.
at least Gem uses the last option to register it's classes (without having to enumerate them; in the light of 200+ objects, it seemed like a clever idea back then...)

and you also need to cater for hexmangled _setup function, which I think would add even more confusion to the actual name of the setup-function.

finally, it requires code-changes for each and every library to support double-precision builds.
in contrast, my proposal should allow to compile any (well-written) external without any code-changes and a single preprocessor define (or a one-line change in the included Pd-header, if injecting preprocessor defines is unfeasible)

[umlaeute]

however, there is one drawback in my proposal: an external that is compiled for double-precision (either as "only double-precision" or "single + double-precision") will not be loadable by a legacy Pd.