Refactor hex decoding

[tadzik]

Description of change

Factors out the hex string decoding. I'm following the pattern established by opt_int_encoder rather than a full-blown custom field like in the issue description, to keep up with existing conventions and not introduce too much magic.

Links to any relevant issues

Fixes #1555

Type of change

• Refactoring

How the change has been tested

I didn't get tox to work yet, so I'm hoping the CI will run the tests for me :)

Change checklist

Tick the boxes that are relevant to your changes, and delete any items that are not.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked that new and existing unit tests pass locally with my changes

[tadzik]

Testing deferred to #1558 while the bindings are borked.

We have existing unit tests that sort of cover this, but a) they don't run b) I can't check if they'd break if this did. Will come back to it later.

[thibault-martinez]

Just checking in, did you come to the conclusion it was not worth to do it for the whole field?

[tadzik]

Just checking in, did you come to the conclusion it was not worth to do it for the whole field?

I didn't see any prior art (in our code or otherwise) in building custom fields like that, but we (and the dataclass_json docs) both use the thingy with custom encoders and decoders – so I figured I'd stick to that. It also avoids the problem of potentially having to extend the field initializer in the future were we to customize it somehow, which @DaughterOfMars brought up yesterday.