while debouncing this call can save re-layouts of the DOM, with indeterminate
streams of redraws coming from Pd it can result in no re-layouts at all. In
the case where a user opens a subpatch that has a redraw triggered by a
[metro 200] object, there may not even be an initial layout. This can result
in the patchsvg never getting its viewBox set and appearing not to display
at all.

One workaround could be to do an initial call immediately after mapping the
window, but there are still cases (like resizing a window or adding objects)
that could result in putting off a needed re-layout for too long.

So instead of debouncing, we throttle. This means there will only be a
single call every 250ms (or whatever value we want), but that call is
_guaranteed_ to happen at the end of the chosen duration. So for a stream
of redraws coming from a [metro 200] we'll get a re-layout every 250ms. That's
more expensive than putting them off indefinitely, but obviously more
responsive and usable.

Ideally we would send a do_getscroll _first_ and then wait 250ms. That would
result in a more responsive UX-- as it is the 250ms makes the initial window
rendering appear sluggish. Unfortunately there's still some kind of race
between the rendering of the window menu and the window size measurements
reported by the DOM API-- if we measure too early the vertical measurement is
too big, resulting in an unnecessary vertical scrollbar.

So instead we wait 250ms and call do_getscroll after. This apparently
gives enough time for the menubar to render and for the DOM to take it into
account when feeding us the window dimensions. But if that race can be fixed
or worked around, we can change the behavior here to call first then wait
second.

Save the defaults on OSX if the user prefs don't exist yet, in order to avoid losing them later when saving the recent files list (fixes #339).

use "legacy_" prefix to guard against namespace collisions (plus self-documentation of the relevant classes)

add some rudimentary mouse tracking objects so that the questionable C code in the various mouse-related classes can be replaced with abstractions

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

commit dc79deff7b8e89edc4e97557e7b76c0afce0fea3

Pd Vanilla commit 98b4959f03f0fd9acfd7c117d8061589504c89e6

This reverts commit 16973649, reversing
changes made to 15094e4c.

Conflicts:
	pd/src/m_pd.h

fix error where the "$@" variable was overwriting the bounds variable for the loop used to check for its existence

fix a very nasty utf8 code-point counter/offsetter that can easily dereferencing garbage thanks to Pd's use of non-null-terminated strings