Fix output_verbosity Literal to accept int values for unittest tester

[donny-wong]

Problem

output_verbosity in PyTestData (shared by the pytest and unittest testers) was typed as a string-only Literal. The unittest tester uses integer verbosity levels (0/1/2, matching Python's unittest), and the MarkUs form already emits these ints — the manually patched JSON Schema enum allowed them. But the Struct type did not, so msgspec would reject an int-valued output_verbosity on decode.

We don't currently decode tester configs with msgspec (we read them as plain dicts), so nothing is breaking today. This aligns the type with the data and the already-patched schema so we're ready if/when we adopt msgspec decoding.

Fix

Adding the ints as a single mixed Literal[..., 0, 1, 2] isn't viable: msgspec.json.schema_components sorts Literal values to build the enum, and sorting mixed int/str raises TypeError: '<' not supported between instances of 'int' and 'str', breaking schema generation. So output_verbosity is now a union of two same-typed Literals:

pythonLiteral["", "short", "auto", "long", "no", "line", "native"] | Literal[0, 1, 2]

msgspec emits this as an anyOf of two enums. In settings(), the old hardcoded enum patch is replaced with a step that flattens that anyOf into a single flat enum, which is the shape the form (rjsf) expects. The allowed values now live in the type and drive both validation and the generated schema, rather than a separately maintained hardcoded list.

[david-yz-liu]

Thanks, @donny-wong!