Enum discriminants should be taken from the end of the input string, like lengths

The same rationale for why we take lengths from the end of the input byte string applies to discriminants: depending on the discriminant chosen, it changes which subsequent arbitrary calls are made and how many bytes are needed. It generally seems best to have "control flow"-y choices that affect shape be taken from the end of the input string and "filler" data taken from the start.

To do this we'll need to expose our internal int_in_range that takes from the end. Not sure what to call it, or how to explain why there are two variants in the documentation well...

Start by locating the internal int_in_range entry point and the code that chooses enum discriminants, then compare their behavior with the linked FuzzedDataProvider rationale. Determine how to expose the end-consuming variant and document why both variants exist. Done means discriminants are selected from the end of the input while preserving the intended arbitrary-data behavior.