Change the mpfr rounding method

[cxzhong]

It mainly about this
Modify rounding method to use banker’s rounding by cxzhong · Pull Request #41268 · sagemath/sage
I would like to change the default rounding method of MPFR number from rounding to infinity to rounding to even. to satisfy the python's general implement
and you can also see the discussion in  Fix incorrect tests and override canonical associate by cxzhong · Pull Request #41288 · sagemath/sage
Thanks
Chenxin

[cxzhong]

I think this fixes the strange behavior like
```
sage: (5/2).round()
2
sage: (-5/2).round()
-2
sage: (2.5).round()
3
sage: (-2.5).round()
-3
```

[cxzhong]

I have opened a new PR about this. If we do not want to change the rounding method. we can follow this
Add rnd parameter to RealNumber.round() by cxzhong · Pull Request #41945 · sagemath/sage

[Nils Bruin]

To clarify, it took me/us quite a while to understand why MPFR has what it has; see

https://github.com/sagemath/sage/pull/41288#issuecomment-3671350964

Some takeaways from the explorations there:

 - MPFR is right in having its different "rint_*" routines, as these all have subtly different behaviour and their behaviour cannot be achieved simply by reducing the number of digits and using a rounding mode. That means that borrowing the rounding mode on the relevant "real field" does not solve the problem completely. "trunc, ceil, floor" are still specific

 - IEEE does seem to prefer round-to-even in various settings and so do python floats. 

 - It doesn't look like MPFR made a *choice*. They just provide the different possibilities; not necessarily under a completely regular naming scheme.

 - We should make sure that existing code continues to run; hopefully with the same results, but if really necessary some different rounding would be OK (when you rely on floats there is always the possibility of changes due to versions not quite preserving same behaviour on the bit level). I'd be against any environment variables or global state for this. The rounding issue here is really an edge case and would not matter for code that genuinely depends on floating point, so we should do something sensible but foremost simple. Having to deal with deprecation messages popping up is almost certainly going to be much more disruptive than even a silent change to different sensible behaviour.

Note that the mpfr rounding routines express the resulting  integer value still as an mpfr float with a limited number of bits, contrary to our rounding routine that is supposed to spit out an actual integer.