CompositeMorphism: Add a list-like interface.

This commit adds ``CompositeMorphism.__len__``,
``CompositeMorphism.__contains__``, and ``CompositeMorphism.__iter__``
to make it a little bit easier to use.  This commit also takes care that
``Diagram`` does not confuse a composite for a list of morphisms.
Diagram: Add expanded_generators.

This commit adds the code for enumerating the expanded generators of the
diagram.  There are some intuitive examples of expanded generators in
the docstring of ``_is_expanded_generator``, however, no actual
explanation is provided yet.  The proper explanation will be added
separately, in the commit immediately following the next one.
Diagram: Enforce all generators to be extended generators.

Diagram will now raise a ``ValueError`` if a generator which is not an
extended generator is supplied.  This explicit restriction of the class
of morphisms which can serve as generators is mainly due to how
``Diagram`` handles infinite cases.  In general, it should be possible
to overcome this restriction by carefully handling a number of corner
cases, but, apparently, it's not yet worth it.  Should the need for such
unusual generators arise, it can be implemented.

The next commit will add the documentation for the changes introduced by
this and the previous ones.
Diagram: Document expanded generators.

This commit describes expanded generators in the docstring of
``Diagram`` and also adds an example to the docstring of
``Diagram.expanded_generators``.
Diagram: Crank up test coverage to 100%.
Diagram: Review the doctring.

This commit fixes minor typos and some formulations in the docstring of
the class ``Diagram``.
Diagram: Add _morphisms_by_stages.

This method essentially represents an internal version of
``Diagram.morphisms`` which, besides yielding the actual morphisms, also
yields the number of the generation round.  This commit also rewrites
``Diagram.morphisms`` to use the new method.

The point behind having this method is that sometimes is very useful to
distinguish between generation rounds in order to be able to check
certain stopping conditions.  See next commit for an example.
Diagram: Rewrite ``expanded_generators`` to be more general.

Previously, ``Diagram.expanded_generators`` was not able to cope with
the situations when there were several loops or cycles starting at the
same objects or when there were cycles with common egdes.  This commit
implements a much more general approach to better detect expanded
generators by directly checking whether certain cycles or loops are
passed more then once.  This commit also adds some complex tests which
would not work with the previous version of
``Diagram.extended_generators``.
Diagram.morphisms: Describe the properties of the sequence.

This commit adds the description of certain guarantees
``Diagram.morphisms`` gives when producing the morphisms.  These are
some essential properties and a lot of other functions (will) rely on
it in other contexts.
Diagram: Make objects_components a private method.

This property essentially represented some intermediate result on the
way to condensation.  Coexistence of ``objects_components`` and
``condensation`` was therefore redundant.

Note that this change does not influence test coverage, which shows once
again the redundancy of ``objects_components``.
Diagram.condensation: Use Diagram to represent trivial components.

Previously, one-object connected components would be represented as the
objects themselves.  While I initially thought it was a good idea, the
nonuniform representation of components creates a lot of ugly edge
cases.
Add DerivedMorphism.

In some cases is useful to specify that some morphism was obtained from
another morphism.  This is the job of the class ``DerivedMorphism``.
Diagram: Use DerivedMorphism to represent condensation morphisms.

This allows knowing exactly which condensation morphism corresponds to
which morphism in the original diagram.
Diagram: Make expanded_generators return a Tuple

Previously, ``Diagram.expanded_generators`` would return a Python
generator.  Now it returns a :class:`Tuple` which makes it possible to
cache the result.
Diagram: Forbid composites whose components are not generators.

Previously ``Diagram`` would tacitly accept such composites.  However,
since all composites are always represented in a flattened down form,
this would result in tricky situations.

The limitation condition introduced by this commit is not in fact a
serious restriction.  Any composite morphism can be flattened down to a
named morphism or, alternatively, one can just explicitly add the
components of the composite to the diagram.
Diagram.expanded_generators: Optimise the finite case.

Now ``Diagram.expanded_generators`` does not do any complex thinking if
the diagram is finite and just returns the ``Tuple`` of morphisms.
CompositeMorphism: Make flatten return a DerivedMorphism.

Previously, ``CompositeMorphism.flatten`` would return a simple
``NamedMorphism``.  Returning a ``DerivedMorphism`` instead has the
advantages of keeping the link between the two morphisms and, more
importantly, of assuring better comparison semantics.  For example, now
it is possible to distinguish between two flattened morphisms between
the same two objects and with the same name, but which originated from
two different composites.
Assure that all categories classes can be recreated from .args.

This slightly modifies the constructors of several classes in the module
categories (without breaking the old interface, though) and adds the
corresponding tests.