Added new nibs_toward_nonbeamable_components beam format behavior.

The behavior is implemented as a nibs_toward_nonbeamable_components property
initialized through a keyword of the same name.

The behavior is currently implemented on only DuratedComplexBeam.

Consider the following configuration that includes a nonbeamble rest:

    >>> staff = Staff("c'16 d'16 r4 e'16 f'16")
    >>> durations = [Duration(1, 8), Duration(1, 4), Duration(1, 8)]
    >>> beam = spannertools.DuratedComplexBeam(
    ...    durations=durations,
    ...    nibs_towards_nonbeamable_components=True,
    ...    )
    >>> attach(beam, staff[:])

The question is what should happen at format time.

OLD: here's the way DuratedComplexBeam used always to format around a
nonbeamable component like a rest:

    >>> f(staff)
    \new Staff {
            \set stemLeftBeamCount = #0
            \set stemRightBeamCount = #2
            c'16 [
            \set stemLeftBeamCount = #2
            \set stemRightBeamCount = #1
            d'16 ]
            r4
            \set stemLeftBeamCount = #1
            \set stemRightBeamCount = #2
            e'16 [
            \set stemLeftBeamCount = #2
            \set stemRightBeamCount = #0
            f'16 ]
    }

NEW: now it's possible to do this:

    >>> staff = Staff("c'16 d'16 r4 e'16 f'16")
    >>> durations = [Duration(1, 8), Duration(1, 4), Duration(1, 8)]
    >>> beam = spannertools.DuratedComplexBeam(
    ...    durations=durations,
    ...    nibs_towards_nonbeamable_components=False, # <== new
    ...    )
    >>> attach(beam, staff[:])

Which results in this:

    >>> f(staff)
    \new Staff {
            \set stemLeftBeamCount = #0
            \set stemRightBeamCount = #2
            c'16 [
            \set stemLeftBeamCount = #2
            \set stemRightBeamCount = #0
            d'16 ]
            r4
            \set stemLeftBeamCount = #0
            \set stemRightBeamCount = #2
            e'16 [
            \set stemLeftBeamCount = #2
            \set stemRightBeamCount = #0
            f'16 ]
    }

Note that this is a really useful beahvior.

The availability of the behavior on DuratedComplexBeam allows
DuratedComplexBeam to produce output that looks exactly like MultipartBeam.

This gets us one step closer to GeneralizedBeam as a replacement for all beam
classes.

So an important point here is that we should implement
nibs_toward_nonbeamable_components as a behavior on GeneralizedBeam.

MODEL: the idea of a 'behavior' is increasingly important in the ways we are
currently extending the system.