Moved SargassoMeasureMaker from Red Example Score to Blue Example Score. MODEL.

MODEL: the next couple of commits will integrate "makers that implement
a no-argument __call__() method."

Recall that a previous commit message distinguished between "type I" and "type
II" makers.

Type I makers are, for example, rhythm-makers; these makers are characterized
by complex and important initialization (that functions as a type of
configuration) followed by probably repeated calls to the maker's __call__()
method; rhythm-maker-style makers are essentially 'repeat generators' designed
to used multiple times throughout a score. Here's a rhythm-maker being
configured:

    >>> talea = rhythmmakertools.Talea(
    ...     counts=(1, 2, 3, 4),
    ...     denominator=16,
    ...     )
    >>> burnish_specifier = rhythmmakertools.BurnishSpecifier(
    ...     burnish_output=True,
    ...     lefts=(-1,),
    ...     middles=(0,),
    ...     rights=(-1,),
    ...     left_lengths=(1,),
    ...     right_lengths=(2,),
    ...     )
    >>> maker = rhythmmakertools.TaleaRhythmMaker(
    ...     talea=talea,
    ...     burnish_specifier=burnish_specifier,
    ...     )

The rhythm-maker is then called repeatedly:

    >>> maker([(3, 8), (3, 8), (5, 16)])

    >>> maker([(3, 4), (4, 4), (3, 4), (3, 4), (4, 4)]

    >>> maker([(5, 8), (6, 8), (2, 4), (3, 8)])

Type II makers don't yet exist in the mainline. (And, indeed, it's possible
that type II makers may never exist in the mainline because they may all be
idiosyncratic to the work of individual composers.) But the
SargassoMeasureMaker is an example of a type II maker. Here's how you configure
a SargassoMeasureMaker:

    >>> maker = SargassoMeasureMaker(
    ...     measure_denominator=4,
    ...     measure_numerator_talea=(2, 2, 2, 2, 1, 1, 4, 4),
    ...     measure_division_denominator=16,
    ...     measure_division_talea=(1, 1, 2, 3, 1, 2, 3, 4, 1, 1, 1, 1, 4),
    ...     total_duration=durationtools.Duration(11, 2),
    ...     measures_are_scaled=True,
    ...     measures_are_split=True,
    ...     measures_are_shuffled=True,
    ...     )

But note that the way you then call a SargassoMeasureMaker is like this:

    >>> maker()

What will be the output? A list (or selection) of measures of music
prepopulated with characteristic rhythms.

Type I and type II makers are both designed to be configured (ie, initialized)
only a single time. But whereas type I makers are designed to be called
repeatedly after configuration, type I makers are designed to be called on a
single time.

This means that type II makers are essentially *frozen functions*.

This also means that type I makers (like rhythm-makers) are essentially
something like partially-frozen functions or frozen partially-evaluated
functions (in that rhythm-makers are something like functions where all input
arguments but 1 are supplied ... the missing input argument being the divisions
that will be passed in when the rhythm-maker is called).

                                     * * *

The present commit starts the process of type II maker integration by moving
the SargassoMeasureMaker from the Red Example Score to the Blue Example Score.
The reason for this is that the Red Example Score already has five material
packages and the Blue Example Score has no material packages. So it will be
cleaner to integrated type II makers useing the Blue Example Score as a staging
area.

The terminology of "type I" and "type II" will hopefully be replaced with
something explicit during integration. Possible explicit distinctions between
the two types of maker might have to do with the number of arguments supplied
on call (0 for type II makers ... 1 or more for type I makers) or else with the
fact that type I makers are configure-once-call-repeatedly whereas type II
makers are configure-once-call-once.

The point relevant for the IDE will be that the two types of maker will deposit
slightly different artifacts on the filesystem.