`contentHint`: notes aren't normative and shouldn't describe normative behaviour

[padenot]

I just found a tab with my review of #729 unsubmitted, so I'm opening this new issue with my comments:

See contentHint:

NOTE: Any codec-specific encoding options take precedence over contentHint.

This seems to be a requirement, but is in an informative note, and that's not correct. We want to describe in what case and which codec-specific option overrides this contentHint. Also, we might want this for audio, e.g. we could make it map to those Opus flags: https://github.com/xiph/opus/blob/master/include/opus_defines.h#L191-L199

[tguilbert-google]

I will be submitting a PR to add contentHint to AudioEncoderConfig, for that specific Opus use case.

Should we then add text in the registries, and have the main spec defer to the registries?

[chrisn]

@tguilbert-google Adding to the registries sounds good, yes. We may want to add to the registry entry requirements to say that registry entries may add codec-specific options that override contentHint, and we should reword the Note as Paul suggests.