Fix associativity failing in FormalCompositeMap
Correct the previous commit

I've forgotten to add some files before commit...
Replace :meth:`list` by :meth:`__getitem__` in FormalCompositeMap
Depreciate first and second methods.

`meth:FormalCompositeMap.first` and `meth:FormalCompositeMap.second don't make
sense in the new representation, so I've deprecated them and I've added instead
`meth:FormalCompositeMap.head` and `meth:ForamalCompositeMap.tail` (`first`
and `second` are respectively aliases for `head` and `tail`).
Change `FormalMapComposition.tail` (former `.second`) to `.then`.
trac #16464: generic implementation
trac #16464: Docstring work
trac #16464: be more careful with errors
trac #16464: handle correctly arguments for cyclotomic_cosets
trac #16464: Second review
trac #16464: tiny improvements for is_a_splitting
trac #16464: replace bool(S1&S2) by S1.isdisjoint(S2)
trac #16464: move code in commutative_rings and fix doctests
Modify the name `FormalCompositeMap.head()` to `.first()`.
trac #16464: fix doctests
Trac 16291: reviewer patch
changed output of a randomized test to get an error message that makes the failure reproducible
Trac #16464: cyclotomic_cosets for any finite ring

In order to implement difference families (see #16461), I need a method
to list multiplicative cosets of a finite field. Here it is.

See also [[https://groups.google.com/forum/#!topic/sage-
nt/BlkL5JjfXT4|this thread on sage-nt]].

The method `cyclotomic_cosets` is implemented at the level of rings (in
`sage.categories.rings`) and the corresponding global function is
deprecated. The code is also adapted in
`sage.coding.coding_constructions` to take care of the change.

We also correct a bug in `sage.coding.coding_constructions` where
`is_a_splitting` returned a pair and hence '''always''' evaluated to
`True` in if statements.

URL: http://trac.sagemath.org/16464
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix
Reviewer(s): Nathann Cohen
Trac #15639: Random failure in integer_vector

Got this once on skynet/eno:
{{{
sage -t --long src/sage/combinat/integer_vector.py
**********************************************************************
File "src/sage/combinat/integer_vector.py", line 347, in
sage.combinat.integer_vector._slider01.range.gale_ryser_theorem
Failed example:
    for algorithm in ["gale", "ryser"]:                            #
long time
         for i in range(50):                                         #
long time
            if not test_algorithm(algorithm, 3, 10):                 #
long time
                print "Something wrong with algorithm ", algorithm   #
long time
                break                                                #
long time
Expected nothing
Got:
    Something wrong with algorithm  ryser
}}}
Likely due to #15609.

Common Python pitfalls are that the sort order of sets / dict entries
can be dependent on memory locations.

URL: http://trac.sagemath.org/15639
Reported by: vbraun
Ticket author(s): Federico Poloni
Reviewer(s): Volker Braun
Trac #16291: Fixing associativity of FormalCompositeMap

This ticket follows discussions in #16245, comments 4 and 5. This
discussion raised a break of associativity in FormalCompositeMap.

Currently, the `FormalCompositeMap` only stores "first" and "second"
map. Hence `(f*g)*h` builds a tree like:
{{{
|\
| \
|\ h
f g
}}}
whereas  `f*(g*h)` builds a tree like:
{{{
|\
f \
  |\
  g h
}}}

As a result, map composition is not associative:
{{{#!python
sage: from sage.categories.map import Map
sage: f=Map(ZZ,ZZ)
sage: (f*f)*f==f*(f*f)
False
}}}

I think this class should contain a list of several Map. I've made a
draft of it, the only doctest I had to change was those involving
`FormalCompositeMap` string representation. Indeed, this representation
was treelike and is now linear.

URL: http://trac.sagemath.org/16291
Reported by: sbesnier
Ticket author(s): Sébastien Besnier
Reviewer(s): Peter Bruin