Speed up RATIO->FLONUM and INT:->INEXACT by using (INTEGER->FLONUM N

Speed up RATIO->FLONUM and INT:->INEXACT by using (INTEGER->FLONUM N
#b11) when N is small enough that it has an `exact' flonum
representation.  A prior log message comments on this, but the code
does not seem to take advantage.

DISCUSSION:

Question:  why is (INT:->INEXACT N) not simply (INTEGER->FLONUM N #b10) ?

(EXACT->INEXACT (expt 2 3000)) used to fail in INTEGER->FLONUM,
but now it returns MAXDOUBLE (due to ldexp), but an Infinity or an error
would seem better.

R4RS says: If an exact argument has no reasonably close inexact
equivalent, the a violation of an implementation restriction may be
reported.

I would read this as NOT returning MAXDOUBLE as, say, 2^3000 is not
`reasonably close' to any FP number.

A previous log entry says INTEGER->FLONUM does not round reliably.
This is because bignum_to_double in "bignum.c" accumulates, which may
cause error due to intermediate rounding.

Perhaps bignum_to_double should be changed to extract the top 53 bits
and explicitly calculate the exponent; another test would be required
in place of bignum_fits_in_word_p, which does not (and should not)
understand rounding carry.  Currently, calling bignum_to_double on

	(- (expt 2 1024) 1)

signals a floating point overflow or returns an infinity depending on
which FPU exceptions are enabled.

If bignum_to_double was fixed it could be a lot faster than all the
current bignum arithmetic.