Add residue_field() method to polynomials over GF(p)
#17015: upgrade eclib to 20140920
added direct convertion of scipy output
Added a function height() := rank()+1.
Typo correction & change of wording.
Better phrasing for function description.
#17105 upgrade eclib to 20140921
Merge branch 'u/jmantysalo/function_to_check_if_a_poset_containt_a_subposet_isomorphic_to_another_poset' of trac.sagemath.org:sage into u/tscrim/poset_height-17004
Merge branch 'u/jmantysalo/adding_height___function_to_poset' of trac.sagemath.org:sage into u/tscrim/poset_height-17004

Conflicts:
	src/sage/combinat/posets/posets.py
Trac #16946: Add residue_field() method to polynomials over GF(p)

There are lots of commented-out doctests in
`src/sage/rings/residue_field.pyx`, which were added by the patchbomb
#8334. All these doctests pass (with some trivial modifications),
provided we add a `residue_field` method to polynomial rings over a
finite prime field.

URL: http://trac.sagemath.org/16946
Reported by: jdemeyer
Ticket author(s): Jeroen Demeyer
Reviewer(s): Frédéric Chapoton
Trac #17015: Upgrade eclib to version 20140921

A tiny change to make it work ok with pari versions 2.8 and above (and
still work with earlier versions).  Also improved NTL-detection.

New upstream is at
[http://boxen.math.washington.edu/home/cremona/eclib-20140921.tar.bz2]

URL: http://trac.sagemath.org/17015
Reported by: cremona
Ticket author(s): John Cremona
Reviewer(s): François Bissey
Trac #17004: Adding height() function to Poset

The height of a poset is the cardinality of the longest chain and can be
computed by the rank of a poset (the ''length'' of the longest chain)
plus 1.

URL: http://trac.sagemath.org/17004
Reported by: jmantysalo
Ticket author(s): Jori Mäntysalo
Reviewer(s): Travis Scrimshaw
Trac #17011: fix some old scipy-related weirdness in functions/special.py

In couple of places the conversion from scipy complex number to Sage is
done via strings, which is probably some old relic going back to 2008 or
so.

As well, the type of the returned number is default Sage's data, rather
than C/RDF, as it should be, to avoid confusion about precision of these
computations, cf e.g. http://ask.sagemath.org/question/24163/why-does-
sage-offer-unusable-scipy

URL: http://trac.sagemath.org/17011
Reported by: dimpase
Ticket author(s): Dima Pasechnik
Reviewer(s): Volker Braun