Fix some bugs with printf and BigFloat

[ScottPJones]

This fixes a couple of issues with @printf and @sprintf, when using BigFloat types.
The Printf code allocates only enough space for the largest number that can be output with the "%f" format for the Float64 type.
Also, the old code doesn't correctly check for the case where mpfr_snprintf truncates the output, because the buffer that was passed was too small. (It needs to check the length required returned by mpfr_snprintf against the amount of room in the buffer that was passed to mpfr_snprintf, and resize the buffer if necessary).
The change also adds GC.@preserve for the buf variable, so that it can't be freed too early.
Finally, if the amount needed is so large that it doesn't make sense to print out the result, it returns an error. (Note: this is because a BigFloat can have a binary exponent of 2^63-1, or approximately 2.8e18 digits)

[JeffBezanson]

This cutoff seems pretty small to me --- 4k is not an unreasonable amount of data.

[ScottPJones]

That's for a single BigFloat, which would mean a precision of over 13600 bits to hit that limit (I hadn't heard of anybody using more than 1024 bits for BigFloat, so I thought that 4096 would be large enough (and definitely better than the current behavior of just giving a garbage truncated result with lots of \0 bytes)
I can change that to use something like the min(__BIGFLOAT_LIMIT__, ceil(Int, precision(arg)*log(2)/log(10)) + 32), so that it would always be able to output (in a round-trippable fashion) any BigFloat using %e or %g, as well as handle any size up to BIGFLOAT_LIMIT for %f whatever you think that should be set to, because of the 64-bit binary exponent having to be output as 0's or extra digits).
Given that an 10^89 is considered enough to represent all the particles (+ photons) in the observable universe, it seemed to me that 4096 would be large enough. Are there mathematical cases where that many digits are really required for floating point numbers?