Remove weird Rational dispatch and add pi functions to list

[gbaraldi]

Should fix #48735

[oscardssmith]

This is mostly good but I have 2 nits. The first is that there's now some useless complexity in the sinpi(_x::IEEEFloat) methods from when they also needed to support Rational. The second is that it probably would be a good idea to change the IEEEFloat methods to AbstractFloat methods and define sinpi_kernel(x::AbstractFloat) = sin_kernel(x *pi) etc. This would increase accuracy since the multiplication by pi would be done after the reduction. (If you do this though, keep in mind that maxintfloat(::BigFloat) isn't a fixed number).

[gbaraldi]

BigFloat should never take this path anyway, mpfr has sinpi and friends already.

[gbaraldi]

By useless complexity you mean the

    if T <: AbstractFloat
        x >= maxintfloat(T) && return copysign(zero(T), _x)
    end

I can remove it, no worries.

[sostock]

This does resolve #48735, but the fact that the conversion from rational to float now happens before the range reduction introduces new inaccuracies:

Julia 1.9:

julia> sinpi(typemax(Int)//2)
-1.0

This PR:

julia> sinpi(typemax(Int)//2) # conversion to Float64 results in an integer value
0.0

[gbaraldi]

That's annoying, because the float cast makes us avoid the overflow that happens with

sinpi(typemax(Int64)//1)

But it makes us lose precision because we don't do range reduction, except that it is the range reduction that overflows 😮‍💨

[gbaraldi]

1.9 was already broken in a similar case to this, if your number isn't really representable with a float64 and you want to get an accurate float64 at the end I'm not sure if there is anything we can do except recommending that you switch to BigNums

r = 2//9167316862078496223
sinpi(r)

1.9 gives the overflow error here while 1.10 gives a result which is kind of close to what BigNums get, but again it's at the limit of the precision.

[oscardssmith]

imo this is ready to merge