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]

I was talking to my coworker @LaurentGoderre about this today, and he pointed me at https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter and https://github.com/jsdom/whatwg-mimetype which have some of that "why is this a thing?" flavor I was suggesting we need to look for in one of the weekly OCI calls a while back.

I don't think it's a perfect slam dunk "yes, we need to support these" but also sheds even more doubt (IMO) on whether we can reasonably apply a blanket "thou shalt not" on them either, so I'm personally leaning towards a NACK here.

[sudo-bmitch]

In the scenario of an artifact type set to text/html;charset=utf-8", either in the manifest, or on the query string for the referrers API, should that be allowed, should it be an exact match, or should the server ignore the parameter when performing a match for the referrers listing?

Thinking of the risks of changing our mind in the future, allowing it today and denying it in the future would mean existing content on registries is no longer valid. But the reverse, denying it today and later deciding to allow it, would mean older registries and clients would reject new content. Neither is great, but the latter is at least feasible to me (I'd reject a change that invalidates existing valid data without a good reason).