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

The build directory needs to be cleaned out for a subsequent rebuild to work in the Darwin app build.

* Tab bar is 100% width

* Startup tab has proper right margins

* Startup tab buttons are properly aligned

* All select (dropdown) boxes are the same height as the numboxes

* Better spacing on midi in and out labels and between select boxes

* Better spacing and sizing on the audio input and output select boxes, associated channel numbers, and labels

* More spacing between audio input and output

* This is a missed case scenario that applies only to symbol gatom when it receives a symbol that sets its value via its inlet

Proper fix for centering the save dialog prompt

* Prefs top tab bar is now stretched across the full window width

* All close buttons are a bit better spaced from the right edge, so that the top and right and bottom edges are as similar as possible

* Initial addition of the gatom extended editing abilities. Shift+click allows for append to the previously entered values, whereas click behaves as it always did. Shift+Backspace when in append mode deletes everything. Dragging number up and down with a mouse now allows for dynamic switching between the shift (fine-grained) and non-shift mode.

* Further refinement to the vanilla numbox, so that it can use the same keyboard shortcuts as the numbox2. Also fixed a crasher from the earlier implementation.

* Disabled debugging

* Activated gatom does not highlight both data and label anymore

* Previously reinstantiation only worked every other time the object was deselected. Now we force it to properly reinstantiate after each deselect.