Prevent intervals from exploding

[Xendergo]

With repeated computations, intervals have a tendency to explode in both precision and size, leading to dramatic performance degradation. This PR changes select_root to reduce the precision of the interval as much as possible and then shrink it as much as possible.

For example, my code bogs down on things like...

RealAlgebraicNumber {
    minimal_polynomial: -2 + 0*X + 1*X^2,
    interval: DyadicFractionInterval {
        lower_bound_numer: -10571651074637012948606856207467025547659003845587123402693454506352325501877985104061960876205698856772420571402777161415701715738538773671892007249382636968910741152877047743937532853909051688801936626558579251792110086179246068196452222130739340925889674214193044358757440449343027549624036504548024882786835914100250307315515920110203530835949165960922917715319016182371,
        upper_bound_numer: -2128247167973908800808043720912013659097287047381664036097907236208011560533561291970063899535,
        log2_denom: 311,
    },
}

and

RealAlgebraicNumber {
    minimal_polynomial: -1 + 0*X + 3*X^2,
    interval: DyadicFractionInterval {
        lower_bound_numer: -218166975906316027642250384924714131151691425322337138315035168168024728209941639043531136961317245491627261905803214263309757374798474533997366374615989032145095720091079375,
        upper_bound_numer: 0,
        log2_denom: 108,
    },
}

which my code doesn't under this change.

An alternative strategy would be to remove the shrinking phase and to refactor dyadic intervals to always consider the upper bound numerator to be the lower bound numerator plus one. I suspect that that would be a nice cleanup and reduce the amount of math required in general, but it would be a more in-depth refactor and a breaking change given that the interval code is public. I can try that out if you want...

[programmerjake]

please add some tests that check that the intervals don't explode.

Changing how DyadicFractionInterval works internally to guarantee the numerators are at most 1 apart isn't going to work very well because basically all math operations on DyadicFractionInterval expand the numerator range because they can't represent the result exactly so have to round. Also, some intervals already have a denominator of 2^0 so they can't just reduce the denominator.

[Xendergo]

Makes sense, I added some testcases

[programmerjake]

you can just use num = num.pow(2);