remove '' option for all but int and string

An mpf value does not store information regarding precision; it just
stores the sign, odd mantissa, power of 2 and the *bit count of the
mantiss*. That last quantity is not a precision. Trying to create an
mpf from different precision strings does not change the underlying
mpf tuple that is created:

>>> mpf('88.00000000') == mpf('88')
True
update Float._new since Float(Integer) returns Float

Also, add more to the docstring of mpf_norm regarding what
it does and doesn't do.  Here is an example of ill-formed
mpf's giving bad results:

>>> mpf_norm((3,123455,0,4), 3)
(1, 1929L, 6, -2)  <======= negative bitcount
>>> mpf_norm((3,123455,0,22), 1) <====== hangs

Both of these problems would not occur if the proper bitcount
of 17 were used instead of 4 or 22

>>> mpf_norm((3,123455,0,17),3)
(3, 1, 17, 1)
>>> mpf_norm((3,123455,0,17),1)
(3, 1, 17, 1)
give evalf enough precision to compute number

I'm glad these tests failed. As far as I can see, they should not have
given the exact integer value because the default evalf was used. This
should only have given about 15 digits of precision and then the integer
part of the result would (and was) accurate only in the first 15 digits.
Now a precision of 70 is given which is enough to capture the full integer
part of the calculation.

I did not add tests of int without evalf but do note that one does
not need to evalf the expressions to a known precision in order to
obtain the correct integer part:

>>> int(floor(factorial(50)/E, evaluate=False))
11188719610782480504630258070757734324011354208865721592720336800L
>>> int(ceiling(factorial(50)/E, evaluate=False))
11188719610782480504630258070757734324011354208865721592720336801L