However, we still need to figure out if we want to supress gui_canvas_getscroll
when suppressing the scrollbars. Currently it still gets called, which will
adjust the viewport to make objects at negative indices visible. I think
instead we want to anchor the viewport to 0,0 at top left and supress those
calls to get a nice speedup in the GUI.

This was a consequence of implementing the "-unique" flag. It
required adding a "data-dir" flag to the command line which
through off the _very_ brittle arg parser in the "open" event
callback.

This makes it possible to define an editable viewport outside of which the
contents are clipped.

One big benefit is that the getrect routine doesn't need to fetch the bboxes
of the shapes inside the viewport. It just needs the svg width, height, x,
y, and parent transform. It's also possible to add an optimized branch if
there is no parent transform specified.

One drawback is that the HTML5 method getBBox() includes the clipped content
in its calculation. That means the user will get scrollbars even though the
[draw svg] is clipping the contents which cause the scrollbars. Hopefully we
can just work around this by adding a "scrollbars" method for canvases to
just turn them off altogether.

Code for an experimental [draw array] is also added here. Combining it with
the viewport of [draw svg] will make it possible to interact with arrays of
widgets without the performance penalty normally associated with mouse
motion on Pd canvases.

Also:
* fixes some display bugs in certain cases for [draw image] and
[draw sprite]
* adds a default png for both [draw image] and [draw sprite] if none are
given

This patch makes it possible to have multiple running instances of Purr Data,
and to leverage that interface from Pd-l2ork to get [pd~] working on all
platforms

Some difficulties required revisions to [pd~] in Pd Vanilla's code
* use quoted path args for Windows when starting the [pd~] subprocess
* replace sys_havegui() from Pd Vanilla's recent "threadening" with sys_nogui

The "-unique" flag requires the OSX app bundle to be able to start by calling
the binary in Pd-l2ork.app/Contents/Resources/app.nw/bin/pd-l2ork. This should
also make it possible to run Purr Data on OSX both by using an app bundle
(where the GUI starts the Pd process) and by installing and running from the
command line (where the Pd process starts the GUI)

The "--user-data-dir" flag sets the directory for various nw.js state used
by a running instance. To prevent races nw.js requires that each running
instance have its own directory that is not shared with any other instances.

Setting the value for this flag has two important potential side-effects:

1. If you have a running instance and try to start an additional instance
   that has the same data directory, nw.js will just send an "open" event
   the first running instance and exit the 2nd instance gracefully. This is
   the default nw.js behavior and the default Pd-l2ork behavior as well.
2. If you have a running instance and try to start an additional instance
   with a different data directory than the first, you'll get a fully
   functional 2nd instance of nw.js running. This is the behavior we desire
   when the user runs pd-l2ork with the "-unique" flag.

In each case we set the data dir explicitly in order to get consistent
positional command line arguments in the GUI.

In normal mode Purr Data will use the default data dir as specified in the
nw.js docs for the particular platorm. Since the same default dir is used
each time Purr Data is run, there will be only one data dir that gets created.

When run with the "-unique" flag, Purr Data will append "-$portno" to the
default data directory, where $portno is the port Pd chose to communicate
with the GUI. That ensures that each separate instance of Purr Data can
get a unique data dir.

A side effect is that users may end up generating multiple data dirs that
don't get deleted on exit. But Pd starts searching for available ports in the
same range each time, and unless the user tries to run hundreds of instances
at once this directory spam shouldn't be too big of a problem.

This is another stop-gap due to the GUI interface not protecting against
messages that arrive before the GUI windows has finished loading.

The code for $@ depends on reading a_w.w_symbol values, but the other
A_DOLLAR branch (i.e., for $1 - $n) depend on reading a_w.w_index.

So for the conditional at the top of binbuf_eval, this means that any
normal A_DOLLAR that has its a_w.w_index set is actually trying to read
a_w.w_symbol. On a 64-bit arch with certain compilers, this will result
in a read of uninitalized data in the padding of the part of w_symbol
that exceeds the sizeof(int).

The workaround here is to define a sentinel value DOLLARALL to a negative
int unlikely to ever be used in real A_DOLLAR values. We then use DOLLARALL
to mean the "@" in "$@" so we can create a special branch for it in the
parser.

One consequence-- we probably need to add a special case error when
this value is out of range. So rather than confusing the user with the
mysterious negative value of DOLLARALL we print "$@" for them. (Currently,
the only place I can see this happening is when "$@" is used as the
target for a Pd message.)

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 b72d9703.

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.

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

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.

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