Fix Python int problem with exp_integral

[kcrisman]

In #11143 we weren't careful about Python ints. There are lots of examples of this, so one will want to go through the whole file.

sage: exp_integral_e(int(3),0)
0
sage: exp_integral_e(3,0)
1/2

[eviatarbach]

I'm guessing this occurs in other files too.

I think it's unreasonable to expect everyone adding symbolic functions to worry about this, and certainly users to be aware of it; maybe we could make BuiltinFunction.__call__ automatically convert int to Integer? Or have it raise an error if an int is in the parameters? Allowing int into _eval_ causes other problems too, such as getting expressions with int pyobjects in them, making arithmetic slower, etc.

At the very least, we could temporarily add from __future__ import division in all files that implement symbolic functions; then exact answers wouldn't be returned in all cases where they should, but at least mathematically wrong answers wouldn't occur.

[benjaminfjones]

I think my preference would be either raising a TypeError (and clearly documenting what the allowed types are) or doing Python 3 style division. I don't like the idea of adding an implicit coercion int -> Integer.

If we do type checking in BuiltinFunction.__call__, we should make sure that there isn't a significant performance penalty.

[jdemeyer]

New commits:

​6d10729	Simplify numerical evaluation of BuiltinFunctions
​b6e1ed4	Merge remote-tracking branches 'origin/u/jdemeyer/ticket/17131' and 'origin/u/jdemeyer/ticket/17133' into ticket/17130
​382f97a	Merge branch 'u/jdemeyer/ticket/17130' of trac.sagemath.org:sage into 6.5beta1
​7265989	17130: reviewer's patch: fix typo
​c47dbd4	Fix Trac #17328 again in a better way
​a486db2	Call the factorial() method of an Integer
​68c545a	Fix bugs due to Python 2 int division

[rws]

Looks fine and passes tests in functions/.