Optimized BigInt implementation

[denisrosset]

This augments the BigInt class with a Long field, so that small integers can be handled without allocating a java.math.BigInteger.

The main motivation is to make BigInt a "safe integer" type with a reasonable performance profile in the case it is mainly used to store Long-sized integers; whereas the overhead of the introduced special case is dwarfed by the java.math.BigInteger machinery.

To maintain binary compatibility even if BigInt is a final class, I added a main constructor parameter of type Long; that main constructor is private. The original constructor is now a secondary constructor taking a single BigInteger argument. Logic inside the constructor decides whether to store the value as a BigInteger or Long argument.

This introduces a small memory overhead when BigInt stores a BigInteger (but in turn, BigInteger is a pretty mighty class which allocates an array).

=====

This is a clean-up of #8932 with nicer history; see the original PR for much review discussion.

[denisrosset]

@SethTisue I guess the CI did not like my force push. The build https://travis-ci.com/github/scala/scala/jobs/504678083 is failing because of the unused "longEncoding" method, a problem that was fixed on the force push.

publishLocal works locally for the two commits d931366 and adaef2b

Should I open a new PR and close this one? (I'm now running publishLocal on my local builds -- I guess IntelliJ doesn't have the proper Ywarn-unused flags).

[SethTisue]

Travis likes it now. The Jenkins failures appear spurious and are now re-running.

(The "combined" check only requires every commit to be green on Jenkins... whatever went wrong on Travis-CI before won't matter.)

[denisrosset]

@SethTisue I have no idea of the cause of the failures above ( 2e67ec1 not passing, but 7cc2a07 passing where I added only a comment line).

Is it due to the force-push?

Anyway, the two PR contain exactly the same code, and the history here is pretty clean.

1. The commits a378d83 0ae2ff9 provide additional tests/benchmarks
2. The commit d931366 prepares the code so that future invariants are enforced (probably with a temp. loss of performance)
3. The commit adaef2b changes the BigInt internal representation, but keeps performing operations using underlying BigIntegers (temp. slower)
4. The commit 2e67ec1 implements the optimized operations using the new internal representation
5. ( 7cc2a07 is a comment to safe guard possible reuse of the longGcd implementation elsewhere )

[SethTisue]

I don't know what happened, but Travis-CI went green when re-run.

[SethTisue]

Let's merge this on Thursday unless there is further review feedback.