The Ctrl+D keyboard command in the help browser adds a bookmark for the
current browser directory, Shift+Ctrl+D removes it again. Note that the
same directory can be bookmarked multiple times (using Ctrl+D), in which
case the same number of delete commands (Shift+Ctrl+D) are required to
delete all instances of the bookmark again; at any time, the oldest
instance will be removed first.

This also provides a (really simplistic) way to reorder bookmarks, since
you can re-add an existing bookmark and delete its older instance
afterwards, which effectively moves the bookmark to the end of the
bookmarks section. It goes without saying that this becomes rather
laborious if you have to manage a lot of bookmarks, so in that case you
might prefer to just edit the bookmarks file (see below) in your
favorite text editor instead.

Bookmarks are shown in their own "Bookmarks" section at the bottom of
the toc, after the built-in toc sections. The "Bookmarks" section title
will be visible only if there are any bookmarks. As with the built-in
toc items, clicking on the title of a bookmark takes you to the
corresponding directory, which may be in the doc or extra hierarchy, or
anywhere else on your hard disk. If a <dir>-meta.pd file in pddp format
is present in the bookmarked directory, the browser will try to extract
title and description from the NAME and DESCRIPTION tags in that file,
otherwise it simply uses the basename of the directory as title and
leaves the description empty.

The bookmarks are stored permanently on disk as a JSON file in the users
home directory, named .purr-data/bookmarks.json on Linux and the Mac,
and AppData/Roaming/Purr-Data/bookmarks.json on Windows. This file is
read each time the help browser opens, so the bookmarks persist across
program invocations, and you can even edit the file manually and reopen
the help browser to make it pick up your changes while Purr Data keeps
running.

This saves time and bandwidth.

Closes jwilkes/purr-data#668

Previously we would redownload the tarball in all cases, saving it
as nwjs-*.tar.gz.1 or similar.

This helps the CI to discover the necessary nw.js tarball while keeping
the logic in one place.

This allows the CI to cache the downloaded tarball. Developers can
manually delete it if needed.

This causes tar_em_up.sh to download an older version of nw.js suitable
for OSX 10.8.

Features:

- Rebuilds and caches the search index if there is no cache yet, or if
  the cache is outdated (i.e., any cached directory or its parent was
  removed or modified since the cache was last created).

- Keeps track of the modification times of all cached directories of
  help files, as well as their parent directories, in order to determine
  when the cache is outdated. The parents are tracked to catch changes
  where new sibling directories are added. This may produce some false
  positives and still isn't 100% foolproof, but it is as close as we can
  get if we still want to achieve substantial speedups.

- Automatically rebuilds the index (and cache) from scratch, as soon as
  the help browser is relaunched after changes to the browser
  configuration in the gui prefs. So there's no need any more to
  relaunch Purr Data to have these changes take effect.

Both the index cache and the directory timestamps are maintained as
ordinary text files with a straightforward syntax (basically
colon-delimited csv) in the user's home directory. The files are located
in configuration directories (.purr-data on Linux and Mac,
AppData/Roaming/Purr-Data on Windows). Thus it's easily possible to
modify these files with external tools (e.g., if we want to upgrade the
file format in the future.)

add an alert system that notifies the user of the existence of unsaved edited instances of the abstraction he is editing or about to edit

Our 32 bit Windows installer currently installs some binaries (dll and
exe files) in the Windows system32 directory. This is unnecessary (all
required dlls are already in the program bin directory where pd.exe will
readily find them), and actually a nuisance, since we currently don't
remove some of the dlls in system32 again when uninstalling, causing a
lot of inconvenient prompts from the installer when upgrading or
reinstalling.

If the user wants to run cyclist, pdreceive, or pdsend from whatever
command line he uses, he can easily add the program bin directory to
PATH himself. That's much better than having our installer pollute the
system32 directory.

The mingw64 build already does it that way, here we simply apply the
same fixes to the mingw32 build.

This discovers user-defined GUI presets (css files) in the css
subdirectory of the gui folder, and adds them at the end of the
corresponding dropdown menu in the GUI prefs. It is a convenience
intended for users and developers who want to experiment with their own
GUI styles.

The predefined presets are still hardcoded in the dialog_prefs.html
file, and are always available (and displayed first in the dropdown
menu). If the preset saved in the prefs doesn't exist anymore (e.g.,
because the user removed its css file), it will be ignored at startup
and the default style will be used instead.

Note that this isn't entirely foolproof since the fallback may not exist
if the user also removed the default.css file. But this could also
happen previously when the css directory gets messed up, and in such a
case the user simply gets what he or she deserves.

In one fell swoop, this solves all usability issues we have with the
Ctrl key we currently employ for that purpose, which interferes with all
our menu keybindings, and makes temporary run mode unusable on the Mac.

Make Ctrl+F work if the canvas is in edit mode. In this case,
canvas_key(), upon receiving the Ctrl keydown event from the Ctrl+F
shortcut, temporarily switches to run mode, but never gets the
corresponding keyup event which goes to the findbox, so temporary run
mode remains in effect when the findbox opens.

This shouldn't actually be much of a problem, but the real trouble is
that while canvas_key() informs the GUI about the change to run mode, it
doesn't update the state of the canvas-local gl_edit variable
accordingly. So when dofind() switches on edit mode later, the engine
still thinks that it's in edit mode and thus doesn't trigger the
necessary update.

The easy fix is to just update gl_edit in canvas_key() when edit mode is
temporarily disabled.

This gets rid of some race conditions in the find operation, by ensuring
that edit mode is only updated *after* mapping a subpatch window.

This bug manifested itself when searching for objects in subpatches
which are not visible at the time the find operation gets invoked. In
this case, on the GUI side we both have to create the subpatch window
and put it in edit mode. In the previous implementation these two
operations would be executed separately and asynchronously. The end
result was that usually the latter operation setting the edit mode in
the GUI would win out, and the edit mode would later get overwritten
again when the window was created.

We fixed that race condition by ensuring that the engine is queried for
its current edit mode status after creating a canvas window. The engine
replies with a call to gui_canvas_set_editmode() in the GUI and thus the
edit mode in the GUI now properly reflects the status in the engine
after a window is mapped.

TL;DR: This fix should now make sure that edit mode on the GUI side
reflects that of the engine at all times.

This makes Ctrl+F work again, by making sure that edit mode is set
correctly in the GUI even if glob_ctrl is set (because the Ctrl key up
event goes to the find box and is thus is never received by the canvas).