Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

[dak]

Ok, this latest iteration is quite close to what I want to end up
committing.  All the work of picking apart articulations and events have
gone into the rhythmic event iterator.  What it does is to broadcast all
articulations that have a listener, and keep the rest as articulations.

One side effect will be that things like c\3 will exhibit a string
number (previously, only <c\3> did).  Another side effect is that tweaks
can work on single notes outside of chords even when those have
non-articulation postevents.

You get an EventChord iff you write < ... >.  A note getting postevents
always receives them in 'articulations, whether it is part of an
EventChord or not.

Postevents on a chord get appended to the EventChord members as
previously.

This is total straightforward.  I have _removed_ the compatibility
option since it
a) considerably complicated code, grammar and semantics
b) was not able to a reasonably reliable job

Instead, it will make sense to write a music function that tacks
EventChord around naked rhythmic events (unwrapping the articulations in
the process) and use that manually
for converting music expressions to the old style when one does not want
to adjust one's internals.

In spite of the remaining problems with spanners and trills (slated to
be removed in the next days), this should be good for testing how
hand-written analysis code fares.  There should be no difference to the
way synthesized code (in the old style) gets typeset.

So give this a testing now or after I shook out the last bugs.  I am
really planning to get this into 2.16.

http://codereview.appspot.com/5440084/