Compressed Texture Formats

The question of compressed texture formats came up in relation to https://www.khronos.org/ktx/
I started WIP json definitions here: https://github.com/KhronosGroup/ANARI-SDK/pull/186/

The gist is that a new sampler type `"compressedImage2D"` is introduced that takes a plain `Array1D` of bytes instead of a 2D array as its image and the format and image size are set via the sampler instead of being derived from the array. The alternative would be to have `ANARIDataType` of compressed texture blocks and then use these in `Array2D` as before. This however creates surprising relationships between pixel sizes and byte sizes of the array. For example a 5x5 pixel texture would consist of 4 BC1 blocks (4x4 each) and therefore have the same byte size as a 8x8 texture. Introducing this kind of information at the sampler stage avoids this complication.

It would however make sense to add a type `ANARI_COMPRESSED_BYTES` to the data type list to indicate the intent of the data. The jsons as drafted above use uint8/int8 however the data can't actually meaningfully interpreted as that and is effectively opaque.

In addition to the compressed sampler extension there are multiple extensions that simply add allowed compression formats (BC, ETC, ASTC, etc.) to said samplers format parameter.

Start by reviewing the WIP JSON definitions in pull request 186 and the KTX reference linked in the issue. Compare the proposed compressedImage2D sampler, ANARI_COMPRESSED_BYTES, and allowed BC, ETC, and ASTC formats. Done means the design is decided and the selected compressed texture behavior and formats are documented.

Written by the indexing model from the issue text.