Use faster Log10 implementation based on the "Bit twiddling" hacks page: https://graphics.stanford.edu/~seander/bithacks.html#IntegerLog10

Also, add more testcases on boundary integers to catch possible
off-by-one errors.

```
goos: linux
goarch: amd64
pkg: github.com/holiman/uint256
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
                      │     old      │                 new                 │
                      │    sec/op    │   sec/op     vs base                │
Log10/Log10/uint256-8   1016.5n ± 6%   762.9n ± 1%  -24.95% (p=0.000 n=10)
Log10/Log10/big-8        27.66µ ± 5%   28.56µ ± 5%        ~ (p=0.393 n=10)
geomean                  5.303µ        4.668µ       -11.97%

                      │      old       │                  new                  │
                      │      B/op      │     B/op      vs base                 │
Log10/Log10/uint256-8     0.000 ± 0%       0.000 ± 0%       ~ (p=1.000 n=10) ¹
Log10/Log10/big-8       22.88Ki ± 0%     22.88Ki ± 0%       ~ (p=1.000 n=10) ¹
geomean                              ²                 +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

                      │     old      │                 new                 │
                      │  allocs/op   │ allocs/op   vs base                 │
Log10/Log10/uint256-8   0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
Log10/Log10/big-8       510.0 ± 0%     510.0 ± 0%       ~ (p=1.000 n=10) ¹
geomean                            ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean
```

Signed-off-by: Evgenii Stratonikov <stratonikov@runbox.com>

---------

Signed-off-by: Evgenii Stratonikov <stratonikov@runbox.com>
Co-authored-by: Evgenii Stratonikov <stratonikov@runbox.com>

…alJSON` (#144)

This PR changes the way marshalling and unmarshalling behaves, in order to maximize compatibilty with `big.Int`: as in, maximize the chance that a 'drop in' replacement of `big.Int` for `uint256.Int` will work seamlessly. 

- `String()` - before this change, `String()` would return the integer in hexadecimal format. This PR changes it to instead return the input in decimal format, like `big.Int` does. 
- `MarshalText()` now returns the integer in decimal format, previously hexadecimal. 
- `MarshalJSON()` now returns the integer in decimal format, previously hexadecimal. 
- `UnmarshalText` now accepts either hex, `0x234` or `234`. Previously it accepted _only_ hex.
- `UnmarshalJSON` now accepts either hex-string, `"0x234"`, dec-string `"234"` or naked numeric decimal  `234`. Previously it accepted _only_ string-hex.

 JSON marshalling is, alas, not 100% compatible, since `big.Int` marshals to json numeric format: `{ Foo: 5}` as opposed to string-format: `{ Foo: "5" }`. The former is not ideal for large numbers, since platforms like javascript do not support arbitary large numbers, usually capped at `53` bits or so. 


TLDR; with this change, some output-formats change from Hex to Dec, but also some input-formats become more accepting. This change achieves better -- but not total -- compatibility with big.Int marshalling.