Quote identifier-shaped numbers (e.g. PDB code 6E72) in JSON output - #445

Thanks, this fixes 6E72 for me. I tried the patch on a few other values (mmJSON options) and have some questions about the scope of the rule.

_entry.id 6E72     -> "6E72"          (fixed)
_a 1E5             -> "1E5"           (string, was number)
_f 12E3            -> "12E3"          (string, was number)
_g 5E0             -> "5E0"           (string, was number)
_b 6e72            -> 6e72            (still a float)
_d -3E5, _e 2E+6   -> numbers         (unchanged, as described)

Questions:

1. Genuine numbers of the shape digits + E + digits (1E5, 5E0) are now strings as well. Is that acceptable, or should the rule be narrowed to the PDB-code shape (exactly 4 characters, nonzero leading digit, e.g. 6E72, 7E57, 1E10)? Some ambiguity remains either way (12E3 is also a valid PDB code), so would a tag-aware rule (_entry.id, _database_2.database_code, data_ names) be preferable?
2. Lowercase 6e72 is still written as a float. PDB ids do appear in lowercase in some sources, so should the check be case-insensitive?
3. The new test uses 1.2E3 and lowercase 2e4, which do not exercise the boundary of the new exception. Could it also cover cases such as 1E5, -3E5 and 2E+6 from the PR description?

For what it's worth, extended ids (pdb_00006e72) are not affected, since the underscore already makes them strings.

Pushed b75edd7 with the narrowed shape. The exception now requires four characters, all digits except a single E/e, so 6E72, 12E3 and lowercase 6e72 quote while 1E5, 5E0, -3E5 and 2E+6 stay numeric. The test covers those boundary cases.

A tag-aware rule would need write_value to receive the tag name, which it does not today. Threading it through the loop and map call sites adds API surface for a case that rarely occurs, since unquoted numberlike tokens in mmCIF show up in id-valued fields. The residual ambiguity (12E3 reads as both a number and a plausible code) remains without tag context either way.