Investigate using Span in BigInteger implementation

[axelheer]

As already mentioned within #22387 the all-new Span should bring many benefits to BigInteger.

• We currently use pointers to spare some index calculations (performance) and "abstract" the differences between ordinary arrays and stackalloc based stuff --> use spans instead
• We currently copy the array containing the actual number after every operation to trim leading zeros --> use span.slice instead?
• And maybe there's more...

We cannot get grid of unsafe code completely since there are stack-vs-heap paths based on stackalloc, but all the pointer based stuff should gracefully disappear; I think.

I'm interested to dive into this, after the summer or so.

[karelz]

cc @stephentoub

[stephentoub]

We cannot get grid of unsafe code completely since there are stack-vs-heap paths based on stackalloc

If that's the only need for unsafe, you might be able to. C# may end up supporting stackalloc'ing directly into a Span, in which case it likely would not require using unsafe.

[ahsonkhan]

If that's the only need for unsafe, you might be able to. C# may end up supporting stackalloc'ing directly into a Span, in which case it likely would not require using unsafe.

It supports this now.
https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

Span<byte> stackSpan = stackalloc byte[100];

[tannergooding]

Marking this as up-for-grabs. Anyone should feel empowered to pick this up and prototype the improvements detailed.