Calling `Base10.decode` may lead to different structures being generated
for use with `uint64`.
The one normally generated is:
```
struct tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg {NIM_BOOL o;
union{
struct {NCSTRING e;
} _o_1;
struct {unsigned long long v;
} _o_2;
};
```
But sometimes, it may be generated as:
```
struct tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg {NIM_BOOL o;
union{
struct {NCSTRING e;
} _o_1;
struct {NU64 v;
} _o_2;
};
```
When the latter is generated, the compiler throws with:
```
error: passing 'tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg' (aka 'struct tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg') to parameter of incompatible type 'tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg' (aka 'struct tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg')
```
for
```
proc getInt*(ht: HttpTables, key: string): uint64 =
let res = Base10.decode(uint64, ht.getString(key))
if res.isOk():
res.get() # This line may lead to the compiler error above
else:
0'u64
```
By passing the type as a generic param, the `unsigned long long` version
gets consistently generated / used regardless of include order.
Minimal POC to trigger the bug, from `nimbus-eth2` root:
```
echo 'import beacon_chain/conf, beacon_chain/sync/sync_manager' >x.nim
nim c -d:"libp2p_pki_schemes=secp256k1" -r x
```
Swapping include order (`conf` after `sync_manager`) works.
* Optimized and exception-less encoding/decoding procedures for decimal integers.
* Add tests.
* Fix import path.
* Fix review comments.
* Code simplification.
* Make toBytes() allocation free.
* Do not perform conversion to signed type to avoid compiler's overflow checks.
