Clarify mediaType and artifactType syntax

[sudo-bmitch]

There was some confusion on whether parameters could be included in the mediaType or artifactType fields. This makes the following changes:

• Consolidates the definition to a single section of the media-type.md file.
• States that parameters are not permitted.
• Includes a regular expression that can be used to validate a string.
• Fixes a regexp bug in our validator that included the range &-^, which inadvertently included a long list of special characters that are not valid in a media type.
• Adds tests for media types with parameters.

[tianon]

Moving this to a common section seems good (instead of repeating it over and over again), but I'm not convinced we have a good reason to limit further than what the RFC specifies? To put that another way, what do we gain from adding extra restrictions on top of the RFC itself?

We've previously discussed (and don't explicitly say anything about) case sensitivity too, as another example: https://oci.dag.dev/?image=tianon/test:sPoNgEbOb

I don't think this is great, but the spec has historically pointed to the RFC as-is. I think it's totally fair for us to say our media types/spec-specified objects shouldn't have parameters, but something about telling other artifact authors they also cannot do so feels off.

[sudo-bmitch]

We were pointing directly to section 4.2, so there's a case to be made by some implementations that we had already excluded parameters that were defined in 4.3 (ECR rejects these manifests today). And schema/defs-descriptor.json almost defined this as a restriction if there wasn't a bug in the regexp.

A big fear for allowing this for fields like artifactType includes the referrers query with an artifactType filter. Should that allow parameters in the query, or should all responses with any parameter be returned if no parameter is included? That part of the spec gets a bit undefined without this limit.