Use fld in _colon method in range.jl, rather than floating point division

[garrison]

This replaces calls to floor(Integer, a / b) with fld(a, b) in _colon(), resulting in simpler and more efficient generated code.

The convert(Integer, ...) is necessary, otherwise the following test fails:

julia/test/ranges.jl

Lines 1524 to 1527 in d8c2250

	# issue #20382
	let r = @inferred((:)(big(1.0),big(2.0),big(5.0)))
	@test eltype(r) == BigFloat
	end

with

  LoadError: MethodError: no method matching StepRangeLen(::BigFloat, ::BigFloat, ::BigFloat)
  
  Closest candidates are:
    StepRangeLen(::R, ::S, ::Integer) where {R, S}
     @ Base range.jl:507
    StepRangeLen(::R, ::S, ::Integer, ::Integer) where {R, S}
     @ Base range.jl:507

I was surprised at first that cld(::BigFloat, ::BigFloat) returns a BigFloat rather than a BigInt, but on second thought, I believe the current behavior is indeed appropriate, as there is nothing to say that BigInt and BigFloat are set to the same precision this is consistent with cld(::Float64, ::Float64) returning a Float64 (see the cld docstring). Hence the convert call in this PR to ensure the returned value is still an Integer.

[oscardssmith]

tagging @StefanKarpinski on these (also #48653) because although these changes look good, I want to make sure he wasn't doing something sneaky.

[jishnub]

I was surprised at first that cld(::BigFloat, ::BigFloat) returns a BigFloat rather than a BigInt

Looks like cld propagates Inf and NaN without complaining. Shouldn't it require that the result is an integer?

julia> cld(Inf, 2.0)
NaN

julia> cld(2.0, 0.0)
NaN

[garrison]

Looks like cld propagates Inf and NaN without complaining. Shouldn't it require that the result is an integer?

Sorry, I have revised my original comment a bit, as it was misleading. It looks like cld(::Float64, ::Float64) is indeed meant to return a Float64, so I believe the current behavior is appropriate with regard to Inf and NaN.

My real surprise, now that I better understand this, is that the BigFloat test is the only one that failed (at least within the ranges tests -- I didn't check any others) before I added convert(Integer, ...).