Fixed OctaveTranspositionMapping copying. Important slots note included.

THIS COMMIT: this commit is trivial: just added an empty __slots__ = ()
definition on the OctaveTranspositionMapping class.  But this commit makes an
important point about how we must implement classes when slots are being used.

BACKGROUND: recall that we've earlier learned an important lesson about using
slots. Assume classes A and B. Also assume A superclasses B. Also assume A does
not implement slots but that B does implement slots. We learned earlier that
this situation is no good. In order for B to get the benefit of implementing
slots, it must be the case that all the superclasses of B must also implement
slots. In this example the only superclass of B is A. So if B implements slots
then A must also implement slots. (And this is the reason that AbjadObject
defines __slots__ = ().)

NEW LESSON: Again assume classes A and B. And again assume A superclasses B.
But now assume that A implements slots while B does not implement slots. Is
this Ok?

It turns out that the answer to this question is more complicated than we have
understood.

First note that we have assumed (up until now) that this second case is Ok. If
A implements slots and B does not then that's fine: A gets the "benefit" of
slots (ie, has no __dict__ and consumes little memory) and B does not get the
"benefit" of slots (ie, has a __dict__) and that's fine: if we later want B to
get the benefit of slots then we can define slots on B then.

But this turns out to be incorrect in one important case. The conflict is a
situation that causes copy.copy() and copy.deepcopy() to break. Easiest to
illustrate with the example that gives rise to the current commit:

Here are the three OctaveTranspositionMapping superclasses; all three classes
implement slots:

class AbjadObject(object):
    __slots__ = ()

class TypedCollection(AbjadObject):
    __slots__ = (
        '_collection',
        '_custom_identifier',
        '_item_class',
        )

class TypedList(TypedCollection):
    __slots__ = (
        '_keep_sorted',
        )

OLD definition of OctaveTranspositionMapping does not implement slots:

class OctaveTranspositionMapping(TypedList):
    ...

Now notice this:

OctaveTranspositionMapping instantiates correctly ...

    >>> mapping = pitchtools.OctaveTranspositionMapping()
    >>> mapping
    OctaveTranspositionMapping([])

... but breaks copy.copy() ...

    >>> import copy
    >>> copy.copy(mapping)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/Users/trevorbaca/Documents/abjad/abjad/tools/abctools/AbjadObject.py", line 66, in __repr__
        return systemtools.StorageFormatManager.get_repr_format(self)
    File "/Users/trevorbaca/Documents/abjad/abjad/tools/systemtools/StorageFormatManager.py", line 311, in get_repr_format
        specification = object_._repr_specification
    File "/Users/trevorbaca/Documents/abjad/abjad/tools/pitchtools/OctaveTranspositionMapping.py", line 119, in _repr_specification
        for mapping_component in self:
    File "/Users/trevorbaca/Documents/abjad/abjad/tools/datastructuretools/TypedCollection.py", line 79, in __iter__
        return self._collection.__iter__()
    AttributeError: _collection

... in a way that should be mysterious. Why is repr complaining that the new
copy of the mapping has no _collection attribute? Why did copy.copy() fail to
provide a _collection attribute? It is clear that the _collection attribute is
defined as one of the explicit slots implemented on TypedCollection. This is
weird.

But it turns out that the situation can be fixed by implementing a (possibly
trivial) definition of slots on the defective class. That is what this
commit does:

    >>> mapping = pitchtools.OctaveTranspositionMapping()
    >>> mapping
    OctaveTranspositionMapping([])

    >>> import copy
    >>> copy.copy(mapping)
    OctaveTranspositionMapping([])

OBSERVATIONS:

1. we've added a new type of slots "discrepancy" to our list of slots
discprepancies. The developer script find-slots-inconsistencies finds cases
where a subclass's slots definition is ineffectual. The new discrepancy
identified here is the inverse of this: where a subclass is missing a slots
definition and it (unexpectedly) breaks copy.

2. the fix is easy: implement a (possibly trivial) slots definition on the
subclass.

3. this is probably what's breaking a large portion of the parameterized copy
tests. as of this commit 35 parameterized copy tests fail and 370 pass. (It was
previously 36 that failed. But OctaveTranspositionMapping now passes.)

4. why aren't *all* slotless classes in the system failing copy? Because for
this error to obtain, the classes in question must inherit an explicitly
slotted attribute from a superclass. If we define Foo(AbjadObject) there will
be no problems because AbjadObject defines an *empty* set of slots. If we
define Foo(TypedCollection) there will be a problem because TypedCollection
defines a nonempty set of slots.
Merge branch 'master' of https://github.com/Abjad/abjad
Merged master.