test(idn-hostname): accept a single label starting with a digit in draft7

[kabirvashisht4-glitch]

Closes #1163.

tests/draft7/optional/format/idn-hostname.json is the only copy of that file with no case for a label beginning with a digit:

{
    "description": "single label starting with digit",
    "data": "1host",
    "valid": true
}

draft2019-09, draft2020-12 and v1 all have it.

How it happened

732e727, the commit closing #686, added five single-label cases to draft-next, draft2019-09 and draft2020-12 but only four to draft7 — the leading-digit one was dropped.

That was deliberate at the time. Five days earlier, 9265a4f (do not test hostname with leading digit for older drafts) had removed the equivalent case from hostname.json for drafts 4, 6 and 7, reasoning that those drafts cite RFC 1034 §3.5 (<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]) rather than RFC 1123 §2.1, which relaxed the rule to permit a leading digit.

That rationale no longer holds for draft7: 9b8ef53 (Cleanup hostname tests) reinstated the case, and tests/draft7/optional/format/hostname.json has asserted "1host" is valid: true ever since.

The inconsistency

draft7 currently accepts 1host as a hostname but says nothing about it as an idn-hostname, even though draft 7 §7.3.3 defines the latter in terms of the former:

idn-hostname: As defined by either RFC 1034 as for hostname, or an internationalized hostname as defined by RFC 5890, section 2.3.2.3.

This is also what #686 asked for — "idn-hostnames also reference RFC 1123, and thereby allow hostnames with single labels. We should copy these tests there as well." — draft7 just didn't get the full set.

The case is added at the position it occupies in the other drafts, making idn-hostname.json identical across draft7, draft2019-09, draft2020-12 and v1 apart from the schema object.

Verification

bin/jsonschema_suite check passes 11/11 with no skips (jsonschema==4.19.0).