feat: de/serialize based on human readability

[kariy]

This PR improves the serde impls used to mainly de/serialize the FieldElement type. The de/serialization implementations now take into consideration whether Serialize/Deserialize implementations should expect to de/serialize in human-readable form or not.

This possibly(?) introduces a breaking change due to this PR #527.

[xJonathanLEI]

This PR is all good by itself. I wanted to merge it, but it this is an unfortunately timing to introduce a breaking change as we're migrating to the official Felt type. Asking users to deal with a breaking change only to immediately break them again via the migration doesn't sound like a good idea. That's the reason for the long delay.

[kariy]

This PR is all good by itself. I wanted to merge it, but it this is an unfortunately timing to introduce a breaking change as we're migrating to the official Felt type. Asking users to deal with a breaking change only to immediately break them again via the migration doesn't sound like a good idea. That's the reason for the long delay.

Understandable! It's not urgent for now so I don't mind the delay 👍.

[xJonathanLEI]

Rebased and added a new bound check for deserializing as the new Felt type accepts any integer input, which makes sense as they can always just take the modulo, but it makes little sense to me for deserialization purposes - you'd never serialize the value into an out-of-range value in the first place.

[xJonathanLEI]

I feel like we need more tests as new functionality has been added with this one.

[xJonathanLEI]

Hmm an issue with this PR is that it leaves UfeHexOption unchanged. So it gets a bit weird.

[xJonathanLEI]

Just pushed a commit adding binary serde to UfeHexOption and UfePendingBlockHash too. When the value is None it encodes an empty slice.

[kariy]

thanks, appreciate the help!!