mpfr: Update to include the latest four bug patches

mpfr: Update to include the latest four bug patches

- The base version has not changed but patches to fix 4 bugs have been released.
- Update to rootfile not required.
- Bug fix changelog
	1    A test of the thousands separator in tsprintf.c is based on the output from
              the GNU C Library up to 2.36, which is incorrect. The output has changed in
              2.37 (partly fixed), so that tsprintf fails with glibc 2.37. The
              tsprintf-thousands patch modifies the test to conform to POSIX and also
              avoid the buggy case in 2.36 and below. However, this new test, which was
              expected to succeed, triggers a serious bug in 2.37
              (bug 30068 / CVE-2023-25139). We did not modify the test again since this
              bug affects MPFR's mpfr_sprintf function, with a possible buffer overflow
              in particular cases. This bug has been fixed in the 2.37 branch. In short,
              this patch is useful (and needed) for a fixed glibc 2.37 and some other
              libraries, depending on the current locales.
	     Corresponding changesets in the 4.2 branch: 4f03d40b5, 78ff7526d, e66bb7121.
	2    The mpfr_ui_pow_ui function has infinite loop in case of overflow. This can
              affect mpfr_log10, which uses this function (this is how this bug was
              found). This bug is fixed by the ui_pow_ui-overflow patch (with testcases).
	     Corresponding changeset in the 4.2 branch: 0216f40ed.
	3    The tfprintf and tprintf tests may fail in locales where decimal_point has
              several bytes, such as ps_AF. This is fixed by the multibyte-decimal_point
              patch, which makes the tests aware of the length of decimal_point.
	     Corresponding changeset in the 4.2 branch: 0383bea85.
	4    In particular cases that are very hard to round, mpfr_rec_sqrt may yield a
              stack overflow due to many small allocations in the stack, based on alloca().
              This is due to the fact that the working precision is increased each step
              (Ziv loop) by 32 or 64 bits only, until the approximate result can be
              rounded (thus we have an arithmetic progression here, while a geometric
              progression is used for the other functions), and that at each iteration,
              the previous allocations in the stack cannot be freed. Individual
              allocations in the stack are limited to 16384 bytes, so that the issue can
              occur only when there are many iterations in working precisions that are
              not too large, which is possible with an arithmetic progression. This bug
              is fixed by the rec_sqrt-zivloop patch, which changes the Ziv loop to use
              the standard MPFR_ZIV_* macros; the patch also provides a testcase obtained
              by a function that constructs a hard-to-round case involving large enough
              precisions (this function is commonly used in the MPFR testsuite, but not
              with so large precisions). This bug was originally reported by Fredrik
              Johansson.
	     Corresponding changeset in the 4.2 branch: 934dd8842.

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>