Move `ImageAsset`, `ImageDecoder`, and other related classes to a new library

[kring]

It would be better to decouple image functionality entirely from CesiumGltf and CesiumGltfReader where possible. This avoids situations like having to include CesiumGltf only for ImageAsset, as noted in this comment.

[javagl]

^{(Triggered by this (and the source, https://github.com/CesiumGS/cesium-native/pull/208#discussion_r615892972 ) being open in some abandoned Browser Tabs for nearly a month now: )}

The solutions for this range from

• A CesiumUtilities::ImageLoader class with a single static loadImage function that essentially wraps stb-image away. That would be good: It would make dependency management easier and clearer, and would allow to quickly try out other PNG decoders to see whether they are faster (the image deconding is a severe bottleneck right now). But some questions to think about: 1. Would CesiumGltf* have a dependency to CesiumUtilites then? (probably yes, is this desired?). And 2. we all know that this will not be sufficient in the medium- or long term, so how far will we go towards the second option:
• A CesiumImages library. This would allow to define a clearer dependency. (I mean, what are CesiumUtilities after all?). The API of this library could be relatively small, and mainly wrap stb_image in the first shot, but should already be laid out keeping in mind that this library will/should also support things like KTX2 in the near future.

People who have already looked into KTX2 might give some hints for the second option. KTX2 regularly discussed in the 3dformats calls, but I'm not familiar with it on a technical level. For example, I assume that medium-term, a single, static ImageLoader::loadThat(rawData) will not be sufficient. There will likely be some sort of configuration object like

struct ImageReaderParameters { 
    bool decompressThisAndThat; 
    int compressSoManyComponents;
    bool retainThisAndThatInformation; 
    ...
}

The result may not be a single CesiumImage with uint32_t rgba pixels, but something that can transport other forms of image data, and maybe even some sort of Mipmap levels or metadata or whatnot.

And ... this issue is talking about image loading. Image writing will also be a topic (although with much, much lower priority, of course - at least for cesium-unreal. The tilers folks might want some writeKtx(pixels) function rather sooner than later...),

[javagl]

If this was implemented, it would also fix https://github.com/CesiumGS/cesium-native/issues/150