builtin/test: refactor the Token enum to be more granular

[The0x539]

Description

This feels somewhat ambitious, but shouldn't actually disrupt any of the "interesting" parts of the parsing or evaluation logic.

• By separating "unary primary" and "binary primary" tokens into their own sub-enums, the respective matches can be exhaustive with no fallback error case, and the TokenInfo struct, with its flags field, becomes redundant.
• Further separating the sub-enums makes it easy to factor out the logic associated with each group. The best examples of this are the StatPredicate and NumberComparison cases.
• The token field on CombiningExpression was already unnecessary, but these changes made that fact visible, because the only time it was accessed was to validate that it's a combiner token (which would be trivially guaranteed now).
• I also made some minor control flow tweaks in relevant functions to use expression-oriented returns and/or pattern matching. In a few cases, this looks like I rewrote most of the function, but on closer inspection, the code's largely unchanged.

I am not attached to any of the names, and am open to alternatives.

TODOs:

(N/A, no user-facing changes)

[mqudsi]

I'm not going to bikeshed about the names, but I approve of the general idea. It's slightly less immediately obvious where to add new functionality but I think on the whole less brittle and more maintainable. Good work.