Reconsider division of glTF and 3D Tiles functionality into libraries

cesium-native jumps through some hoops in order to minimize the dependencies of its glTF and 3D Tiles support. Specifically, it divides up the functionality into a whole bunch of different libraries. Let's look at glTF. The glTF support in cesium-native is divided into four different libraries:

1. `CesiumGltf`: This is meant to have nearly zero dependencies on anything, so it can be used independently in almost any project. Perhaps even as an alternative to tinygltf. In practice, it depends on `CesiumUtility` and `GSL`, and the dependencies of `CesiumUtility` have been growing over time (as they often do) and now include `glm`, `uriparser`, `spdlog`, and `zlibstatic`. 😬
2. `CesiumGltfReader`: Adds the ability read glTF from JSON and GLB. Also knows how to "process" glTFs in various ways at load time, including image (JPEG, PNG, WebP) decoding, Draco decoding, KTX transcoding, Base64 (data URI) decoding, and meshopt decoding. For this reason it depends on a bunch of third-party libraries that implement these things. From cesium-native, it also depends on `CesiumGltf` (of course), `CesiumJsonReader`, and `CesiumAsync`.
3. `CesiumGltfWriter`: The writing side of `CesiumGltfReader`. It doesn't support encoding all the things that the reader can decode, so it has fewer dependencies. Just `CesiumGltf`, `CesiumJsonWriter`, and `modp_64` for data URI base64 encoding.
4. `CesiumGltfContent`: This is a new one that is not in main yet, and I don't love the name. But this is the first library that depends on cesium-native proper, most notably `CesiumGeometry` and `CesiumGeospatial`. If we want to compute a bounding region for glTF, or compute texture coordinates for raster overlay draping, we need those libraries. Basically the idea is that this library contains the higher-level glTF manipulation functionality; anything outside representing the glTF in memory (`CesiumGltf`) or reading and writing it (`CesiumGltfReader` / `CesiumGltfWriter`).

This basic division into four libraries exists for 3D Tiles, too.

So this is a lot of complexity. Is there a better alternative? Does anyone actually care that `CesiumGltf` is usable without most of the rest of cesium-native? Is it at all useful to have a library like `CesiumGltfReader` that minimizes cesium-native dependencies, while basically being no-holds-barred on third-party dependencies?

Some possible alternatives:

## Two libraries

1. `CesiumGltfObjectModel` (better name idea welcome): Contains everything in `CesiumGltf` plus the parts of `CesiumGltfReader` and `CesiumGltfWriter` that do not require third-party dependencies. So this library knows how to read a GLB, but it doesn't know how to do Draco decoding. Depends on almost nothing in cesium-native (in fact we should try to eliminate the CesiumUtility dependency). Doesn't do anything asynchronous because it doesn't depend on `CesiumAsync`.
2. `CesiumGltf`: Contains everything else. Knows how to interpret / decode / manipulate glTFs. Can and will depend on just about anything in cesium-native.

## One library

Just put all the glTF functionality into a single library that depends on whatever third-party and cesium-native libraries are needed. Easy. But then using any part of our glTF support will require using most of cesium-native.

I think the critical question here is whether a low-dependency CesiumGltf is valuable to anyone. If not, combining everything into one library feels like a pretty reasonable approach.

@javagl I'm interested in your opinion on this, including possibly from a Khronos perspective.