The problem that we're trying to solve here is that there is no reliable
way for objects to be notified when the edit mode status of their canvas
changes. This problem exists across various flavors, but is made worse
in Purr Data because it uses an ancient version of the canvas_editmode
method which interprets a zero argument to mean "toggle", not "off".

This makes it virtually impossible for 3rd party objects to observe edit
mode changes while they are still in progress, as they simply cannot
know whether the edit mode bit has already been flipped or not.

The solution: Killing two birds with one stone, we first refactor
existing gui notifications about edit mode changes in various places so
that they now all go through a single function canvas_announce_editmode.
This function then goes on to call the new canvas_dispatch_editmode
function which takes care of notifying all receivers on the C side,
after which the gui gets notified as before.

This also makes sure that the new edit mode status is announced in both
temporary run mode (set in the key handler) and calls to
canvas_editmode and canvas_query_editmode (both direct and through the
message interface), which should cover all relevant cases.

NOTE: The receiver symbol is canvas-specific and takes the form
<canvas>#editmode where <canvas> is the canvas id (hex code), so that
presumably only objects on the specific canvas will receive the message.