Clarify construction of JSON test objects

[johnmhoran]

Some community members have commented on the need to clarify how a JSON test object should be constructed (see the "Tests" section at the foot of PURL-SPECIFICATION.rst). This issue and the associated PR to come will address that need.

(I'll locate and add a reference or two below and will take a shot at this issue.)

[johnmhoran]

See the following re the need to clarify how a test object is to be constructed:

test: unencoded subpath cannot contain . or ..
#368 (review)

docs: how to create invalid cases in the test-suite?
#403

revisit the test suite
#407

revisit test-suite
#409

Here's an outlier example of a test object with a canonical_purl that is obviously invalid, and probably should be null rather than EnterpriseLibrary.Common@6.0.1304:

  {
    "description": "a scheme is always required",
    "purl": "EnterpriseLibrary.Common@6.0.1304",
    "canonical_purl": "EnterpriseLibrary.Common@6.0.1304",
    "type": null,
    "namespace": null,
    "name": "EnterpriseLibrary.Common",
    "version": null,
    "qualifiers": null,
    "subpath": null,
    "is_invalid": true
  }

See https://github.com/package-url/purl-spec/blob/main/test-suite-data.json#L218C1-L229C5.

[johnmhoran]

For an example of how one might properly construct an "is_invalid": true test, see @matt-phylum's comment on an invalid-encoded-colon test.