Memory-managed radix integers and their GR interface

[fredrik-johansson]

We implement radix_integer, like mpz but with custom radix (also, there's no 32-bit restriction for the size and alloc fields). This isn't extremely useful just yet since it's missing a lot of functionality (e.g. division).

As a silly benchmark, let's compute the 10 billionth Fibonacci number, and convert it to a decimal string:

gr_fib_ui(x, UWORD(10000000000), ctx)
gr_get_str(s, x, ctx)

This number has 2,089,876,403 digits.

                             fib_ui    get_str     peak memory

mpz                          50.8 s    532.8 s      5.6 GB
fmpz (flint 3.4)             21.8 s    244.1 s     13.7 GB
fmpz                         21.8 s    132.5 s     13.2 GB
radix_integer                27.9 s      2.6 s     11.7 GB

fmpz          (8 threads)     8.5 s     50.4 s     26.4 GB
radix_integer (8 threads)    11.9 s      2.6 s     14.7 GB

Although radix_integer is ~30% slower than fmpz to actually compute the Fibonacci number, it is 5x faster when including the time for radix conversion.

(Also note that this is on top of the 2x speedup to fmpz_get_str due to the recent upgrade to use radix internally for that conversion.)

mpz_fib_ui / mpz_get_str included for scale. Note that with multithreading, we are now 40x faster than GMP!