This should provide me with the means of testing performance and
correctness of the optimized int64 multiplication algorithm.

Instead of doing bit-by-bit iteration, we split multipliers into 4
16-bit words each and perform long multiplication algorithm on them. A
slight advantage of this algorithm is that it is constant-time, which is
good for cryptographic purposes (although there are probably plenty of
other side channels still).

Optimized algorithm is ~15x faster if you adjust for the cost of array
access:

```
name            old time/op  new time/op  delta
Mul64/noop      3.70ns ± 0%  3.73ns ± 1%   +0.60%  (p=0.000 n=17+17)
Mul64/unsigned   380ns ± 0%    29ns ± 1%  -92.44%  (p=0.000 n=17+20)
Mul64/signed     402ns ± 0%    30ns ± 2%  -92.63%  (p=0.000 n=17+20)
```

This is still several orders of magnitude slower than native 64-bit
multiplication, and at this point the cost is dominated by allocation of
new int64 container objects, which is pretty much unavoidable in
JavaScript.

This test requires regular Go and panics under GopherJS.

In the JavaScript context falling back to 64-bit arithmetics leads to
performance significantly worse that an algorithm using native 32-bit
math, since under the hood those operations are transformed into an
algorithm with 32-bit math, but for a more general case and therefore
a lot slower. Plus inefficiency of our 64-bit representation.

This change shows a significant improvement on `math/bits` benchmarks:

```
Add32            12.7ns ± 0%   1.7ns ± 0%  -86.40%  (p=0.000 n=18+19)
Mul32            58.8ns ± 2%   2.0ns ± 0%  -96.54%  (p=0.000 n=20+18)
Div32             123ns ± 1%    30ns ± 1%  -75.82%  (p=0.000 n=20+19)
``

Note that performance of `math/bits.Add()` and similar have also
improved, since on 32-bit architectures they correspond to 32-bit
valiants. Performance of 64-bit ops remains unaffected by this change
(but did benefit from earlier optimizations).