BigInteger canonical representation incomplete

[ds26gte]

Ideally, each bigint should have a unique (canonical) boxnum representation. Currently, a bigint can have widely different boxnums of the same type (BigInteger) associated with it, and the difference is not meaningful. It is due to unused and unusable information sticking around in the boxnum. It however destroys structural equality of equal bigints.

The code suggests strongly that bigint canonicalization was never a non-goal. There is an explicit subroutine bnpClamp() specifically intended for this, however it fails in two ways:

1. it does an incomplete job
2. it isn't called everywhere it's required

Neither 1 nor 2 is intentional. They are bugs and should be fixed. Fixing them will not break existing Pyret tests. The only JS tests they might break are ones perversely wanting a bigint to not be structurally equal to itself. (We can write such tests. Luckily no such tests exist currently.)

[schanzer]

Tagging #1818 so that this issue can be closed when that PR is merged.