Document experimental feature enum policy

We have a kind of informal system in place where experimental features extending enums explicitly define new enum values in such a way as to not collide with the core values or ones added by other experimental features. For example:
https://github.com/oneapi-src/unified-runtime/pull/1400/files#diff-88d57250473caecebcb2f3e86fe24a0b37df274b69446e5e85335a5cdd649a9cR22
https://github.com/oneapi-src/unified-runtime/blob/main/scripts/core/exp-bindless-images.yml#L87
https://github.com/oneapi-src/unified-runtime/blob/main/scripts/core/exp-command-buffer.yml#L22
To make sure this is consistently followed we should document how we want this to work in here.

We should also evaluate whether we can do without explicitly defining new values like this. Right now the spec and experimental features live in the same place and are delivered as one, there isn't a way for the two to get out of sync, so is there a compelling reason to go out of our way to make sure these enum values remain static?

Start with core/CONTRIB.html#experimental-features and compare the linked exp-bindless-images.yml and exp-command-buffer.yml examples with the referenced pull request. Document the enum-value policy there and record the conclusion and rationale about whether explicitly fixed experimental values are still necessary.