Removed experimental musicexpressiontools package.

ASSESSMENT:

musicexpressiontools constituted the most powerful staging area in the entire
history of Abjad development. Ideas first implemented in musicexpressiontools
included:

    * interpreter
    * score specifier
    * segment specifier (which became segment maker)
    * divisions (which became the output of division makers)
    * timespans (which migrated to mainline timespantools)

These objects and ideas are now all central to working with Abjad in the most
sophisticated way.

Why is it possible to remove the many thousands of lines of code (and,
especially, test artifacts) bundled together in the musicexpressiontools
package? Some parts of the package were migrated months ago to the mainline for
production use (timespantools, extensions to rhythmmakertools, experimental
makertools, handlertools). And other parts of the musicexpressiontools package
turned out not to be necessary after all, the most important case being the
ScoreSpecifier and SegmentSpecifier classes: these are to be replaced by
composers implementing their own SegmentMaker class(es) and using that class
(or those classes) in the production environment established by the Abjad IDE.

The proof points here were the scores that Josiah and I composed this summer
(after two years of combined development on musicexpressiontools,
timespantools, selectortools and the IDE): Krummzeit (in my case) and Zaira (in
Josiah's case). The scores were assembled with unprecedented speed and
formalized control. At the highest level the compositional process for both
scores was the same: implement a custom SegmentMaker class, implement handler
(or agent) classes to work as collaborator classes with the segment-maker; and
then create a series of score segments defined in definition.py modules
resident in segment packages (implemented one per score package), all according
to the filesystem layout, import regime and build and test processes
established by the IDE.

This summer was, then, an applied test case to prove that extensive modeling
done in musicexpressiontools over the course of more than two years was
available in Abjad with the correct interfaces for production work.

Was any functionality not ported over from musicexpressiontools? In fact, yes.
The various affordances implemented in musicexpressiontools to select
divisions, rhythms, components, settings and so on from not-yet-defined points
in both the past and future of a score were never reimplemented in any explicit
way in other packages in the system. This is ok, though, because a better best
practice evolved in place of this: in the end we realized (unwittingly at
first) that the classical inside-of-time / outside-of-time distinction due to
Xenakis fixes these problems for us: the unlimited number of material packages
allowed for by the IDE enable composers to generate arbitrary materials
*outside of time* for inclusion anywhere in the score *inside of time* by means
of a segment definition.py file. In other words, the knitting together of
materials and their in-time positioning explicitly created by the interaction
of IDE material package and segment packages removes the need for the look-back
and look-ahead settings implemented in the now-removed musicexpressiontools.