Either support parsing to/from U256/I256 or remove the variants

[jsdw]

Currently we support decoding and encoding into U256/I256 variants, but both are just represented as arrays of bytes.

Serializing values containing U256/I256's via serde isn't great; they serialize into byte sequences. Deserializing those leaves you with composites; no deserialize input can get out U256/I256; so unlike other types, they don't convert back and forth nicely.

With #7 we cannot yet stringify U256/I256 and we cannot parse strings into them. Parsing isn't as important (we get back a nice error if a numeric string is too big to fit U128/I128) but calling .to_string() on a value containing a U256/I258 will panic. Whatever we stringify should be parsable back again, so we need to add both or neither.

So, do we:

1. figure out how to parse and stringify U256/I256 (my vote; accept numeric strings and parse them into the smallest of U256/I256 or U128/I128 that they will fit into), or
2. remove support for U256/I256 entirely, since they are, from what I gather, unused on the whole (see Add missing 256 bits types which are needed by Solang scale-info#25 for history). Etherum needs them, but parity-scale-codec doesn't support encoding/decoding into them, and without manual TypeInfo impls they will never be seen in metadata.

[gilescope]

I can probably do you a fast U256 string parser if you want one. Pretty sure I have the fastest U128 parser at the moment ( https://github.com/gilescope/atoi_radix10 ) not that anyone has really made use of it yet.

[jsdw]

String parsing to/from U256/I256 would be awesome and would resolve the annoying to_string panic on U256s, so I'd def be up for such things, especially if it was light or no dependencies :)

[jsdw]

(I wonder whether something like https://www.reddit.com/r/rust/comments/vwtfd7/announcing_a_new_big_integer_crate_bnum_which/ would be useful at all, or generally how the current crates compare, but yeah being light on dependencies is important for this crate!)

[jsdw]

We'll likely end up removing the 256bit scale types; see paritytech/scale-info#181