Added SizedInternalFormat enum group for functions that need explicitly sized formats

[NogginBops]

This PR adds a new enum group SizedInternalFormat that is used to more specifically group the enums that are valid in calls to functions such as glTexStorage2D etc.

I could find documentation for most of the functions and enums, but EXT_texture_compression_latc doesn't specify if it can be passed to functions like glTexStorage2D or not, so I decided to not add the SizedInternalFormat group to those.

GL_COMPRESSED_LUMINANCE_LATC1_EXT
GL_COMPRESSED_SIGNED_LUMINANCE_LATC1_EXT
GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT
GL_COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_EXT

I also added the InternalFormat group to a few enums and commands where they where missing. (e.g. glMultiTexBufferEXT)

[pdaniell-nv]

@oddhack this is approved to merge.

[oddhack]

@oddhack this is approved to merge.

Merging, although given comments about potentially breaking ANGLE, perhaps it would be wise to identify a person on that project to sign off on these changes. This is something I was concerned about when the groups started getting actively updated - we have no ability to do more than the most basic sanity checks on proposed changes to the groups, since we don't use them, they don't affect us, and we don't really know who's using them downstream.

[frederikja163]

@oddhack this is approved to merge.

Merging, although given comments about potentially breaking ANGLE, perhaps it would be wise to identify a person on that project to sign off on these changes. This is something I was concerned about when the groups started getting actively updated - we have no ability to do more than the most basic sanity checks on proposed changes to the groups, since we don't use them, they don't affect us, and we don't really know who's using them downstream.

Sorry to revive this, i was just interested in wether or not you would be interested in a list of all projects that use the groups and/or other of the smaller features that arent used internally. This could include things such as the len attributes and more. Im thinking making an issue and pinning it, here projects can then comment if they want to get added to said list.

The list could be used as a reference for what projects use different features and talk with atleast some of them before making changes plus it would better allow khronos to know who is making changes and what their goal is. We could also add some additional contact information/contact people per project using the spec.

If khronos is interested in this i can go ahead and make said issue and i can also be responsible for updating it, at the very least in the near future.

[SunSerega]

Im thinking making an issue and pinning it, here projects can then comment if they want to get added to said list.

I think discussions are, by design, more suited for this. And to make people see this info when making issues - there are issue templates. You can add something like this to the start:

<!--- People that might be affected by XML change, consider mentioning so they can approve --->
[ANGLE](...): @..., this can break ______
Other: @..., this can break ______

[Perksey]

We should move this discussion to its own issue.