Allow converting between nil big.Int and nil uint256.Int

[karalabe]

This is perhaps a debatable change, but may be more logical than originally anticipated.

In some places, having a nil as a big.Int or uint256.Int might make sense (e.g. an optional and non-initialized field). In those cases, converting between the two across older/newer code might be necessary. In it's current incarnation, the uint256 library will crash, so all optional nils need to be special cased.

IMHO this should not be necessary. If a uint256 should not be nil, but a nil big int is passed, then I assume the code later will crash anyway on some uint256 accessor method whether we crash at the conversion or not, so it's not like we're silently swallowing up errors. On the other hand, allowing the nils to be converted back and forth reduces the error potential of forgetting to special case an optional nil somewhere and blowing up runtime.

[holiman]

I agree

[codecov]

Codecov Report

Merging #137 (9053f6a) into master (71f8c05) will not change coverage.
The diff coverage is 100.00%.

❗ Current head 9053f6a differs from pull request most recent head 6ca7b7d. Consider uploading reports for the commit 6ca7b7d to get more accurate results

@@            Coverage Diff            @@
##            master      #137   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines         1615      1621    +6     
=========================================
+ Hits          1615      1621    +6