Reuse the existing infrastructure in GtkActionMuxer for propagation of
accelerator information: in particular, what accel label ought to appear
on menu items for a particular action and target.

This is a good idea because we want accels to travel along with the
actions that they're tied to and reusing GtkActionMuxer will allow us to
do that without creating another hierarchy of a different class for the
sole purpose of filling in accel labels on menu items.

Doing it this ways also allows those who copy/paste GtkActionMuxer to
insert the accels for themselves.

Add a new method on the GtkActionObserver interface to report changes.

This patch introduces a new concept: "action and target" notation for
actions.  This format looks like so:

  "'target'|app.action"

or for non-targeted actions:

  "|app.action"

and it is used over a number of possible alternative formats for some
good reasons:

 - it's very easy to get a nul-terminated action name out of this format
   when we need it, by using strrchr('|') + 1

 - we can also get the target out of it using g_variant_parse() because
   this function takes a pointer to a 'limit' character that is not
   parsed past: we use the '|' for this

 - it's extremely easy to hash on this format (just use a normal string
   hash) vs. attempting to hash on a string plus a GVariant

A close contender was to use detailed action strings here, but these are
not used for two reasons:

 - it's not possible to easily get the action name or target out of the
   strings without more work than the "action and target" format
   requires

 - we still intend to use detailed action strings on API (since they are
   a lot nicer to look at) but detailed action strings can be given in
   non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
   so we'd have to go through a normalisation step anyway.  Since we're
   doing that already, we may as well convert to a more convenient
   internal format.

This new "action and target" format is going to start appearing in a lot
more places as action descriptions are introduced.

I suspect that nobody is using '|' in their action names, but in case I
am proven wrong, we can always switch to using something more exotic as
a separator character (such as '\x01' or '\xff' or the like).