Don't use BigFloat.exact in repr output.

[mdickinson]

repr output for BigFloat objects should show the hex form of the float instead, since recreation is then unaffected by context. str can continue to show a decimal string.

[mdickinson]

At the same time, disable the use of BigFloat.exact for strings: it's misleading.

[mdickinson]

We need to support various cases:

1. Conversion from a decimal string, hex string, integer or float to the current context, taking into account the current rounding mode. This operation is provided by the regular BigFloat constructor.
2. Context-independent conversion from a hex string with given precision in bits, as an inverse to the repr operation. The precision is necessary, since it can't be inferred uniquely from the hex form of the output (unless we use a nonstandard normalization). This could be provided by the BigFloat.exact constructor with a precision argument.
3. Context-independent conversion from a hex string, float, or int, inferring the number of bits necessary to do an exact conversion. (Could also be extended to those decimal strings that are exactly representable in binary, with an error for strings not exactly representation in binary.) This could be provided by the BigFloat.exact constructor without a precision argument.

Proposed behaviour:

• The output of repr should look like BigFloat.exact('0x1234p+1', precision=53).
• The BigFloat.exact constructor should always require a precision.
• The BigFloat.exact constructor should only accept values for which an exact conversion (with the given precision) can be performed. That excludes most decimal strings, for example.
• The regular BigFloat constructor always uses the current context, as before.

[casevh]

Do you even need exact? In gmpy2, mpfr currently accepts base and precision keywords. You could add an exact keyword that will raise an exception is the conversion is inexact. If no precision is specified, then try to determine a precision that is large enough to guarantee an exact conversion. (Ugly hack - I sort of do this already by associating a special meaning to precision=1. It works with float and integers but not hex strings.)

[mdickinson]

Moving this out of the 0.4.0 milestone.