cleanup util::from_hex()

[antiochp]

Our original implementation panic'd if the hex string was an odd number of characters.
This is bad as we use from_hex() when parsing various external ids and hashes.

Edit: We prevented the panic via the janky QQQ parse code (see below). So this PR just cleans it up and adds some better test coverage.

• Simplified the error handling -
  • just return the (invalid) hex string itself as the error
  • got rid of the janky let err = ("QQQ").parse::<u64>();
• from_hex() now takes a string slice rather than a String

This was previously happening if the hex string had an odd number of characters -

panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }'

Edit: There was an edge case where it panic'd. If the hex string was empty -

panicked at 'byte index 2 is out of bounds of ``'

[yeastplume]

I remember that particular piece of Jank. Changes look much better.

[jaspervdm]

The fact that there is some malleability in deserializing shouldnt matter anywhere right? e.g. 0xAAAA and 0x0xAAAA both serialize to the same bytes

[antiochp]

The 0x0xAAAA example is an interesting one - did not think about that. This should be invalid but we permissively accept it.

It may be worth revisiting this and making the prefix logic more strict. But either way this is an improvement over current situation.

I'll merge and we can revisit later.