[NogginBops]

After many attempts at making enum group metadata available in cl.xml (#779, #926, #1145), I've decided to give it a try too.

In this PR I went with the original plan of marking the <enums>-tags themselves with the enum groups the containing enums have, but also allow individual <enum>-tags be marked with additional enum groups that they are part of.
This is similar to how this is handled in gl.xml where the group association is done directly on the enum entries themselves.

Before marking this PR as not a draft I'll probably undo my excessive splitting of <enums>-tags.
My original goal was to only have group="" attributes on the <enums>-tags and not on <enum>-tags but in hindsight this was not necessarily a good idea due to most entries not being grouped by enumeration.

Personally I think I'm leaning towards #926 being the better approach as it is features and extensions themselves that define the typedefs for enum groups so the association between enum entry and type name seems more appropriate there.

The argument for doing the approach this PR does is that it matches how this data is described in gl.xml and there this enum grouping has been very successful. Important to note is that the enum group situation in OpenGL seems to much more complicated than it is in OpenCL and I feel it should be possible to have very accurate enum groups in cl.xml, with enough information the https://github.com/KhronosGroup/OpenCL-Docs/blob/main/man/static/enums.txt file could even be machine generated to always be kept up to date.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ NogginBops
❌ Alexx999
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[NogginBops]

Also, during this work I've found the following issue (#1585) the made it hard to know where to group some enums.

[Kerilk]

I made a slightly different proposal along your lines here #1636, I think it will be slightly less intrusive on the header side right now. Thanks for this proposal, it was very helpful.