no-std support via iterators. fix the tests

[rphmeier]

leads to a version 2.0 bump because of backwards incompability

[debris]

tbh, I created this crate only because rustc_serialize became deprecated and I didn't want to refactor the code to use hex at the time

If you don't mind, please use hex crate instead. I think we should eventually migrate all of our projects to it

[dvdplm]

@debris Right now substrate uses the @rphmeier fork at v2.0.0 and parity-common uses 1.0, so when introducing parity-common in substrate we get both. I don't have a strong opinion (tbh I don't know what it does), but it'd be great to merge this to avoid the maintenance burden of having multiple forks.
I don't mind refactoring both consumers to use hex but I'd like to put it off to later.

[debris]

@dvdplm and how time consuming would it be to migrate substrate to hex? cause rustc-hex never meant to be updated/changed. I'm just afraid that if we merge this pr will be stuck with both versions of rustc-hex for a looong time

[dvdplm]

and how time consuming would it be to migrate substrate to hex?

I have no idea! If you feel that's the best path though, I'm happy to give it a shot and find out. :)

[dvdplm]

For posterity: the hex devs are open to a no-std PR but the two code-bases are by now quite different so it's not just a trivial copy-paste of code from here to there.