Cache images across glTFs to avoid duplication

[azrogers]

As described in #497, sometimes tilesets contain multiple tiles that point to the same image resources. At the moment, these images are loaded once for every tile that uses them, meaning a tileset with 1,000 tiles that use the same image will load that image 1,000 times (and the runtimes will allocate video memory for each of them). This change adds a SharedAssetDepot class that stores images across tiles, and a SharedAsset smart pointer type for tracking and cleaning up the images.

SharedAssetDepot is set up so that in the future, if we need, we can extend this feature to handle glTF buffers as well.

There's a few TODO items currently (besides the runtime implementations):

• Every copy of the image is still counted towards memory used, making the metric inaccurate.
• Currently, the SharedAsset contains either a pointer to a stored asset and counter, or it contains the asset itself if no SharedAssetDepot was provided. This means that the "smart pointer" is at least 96 bytes (the size of ImageCesium), even if it does contain a pointer, which is unacceptable. I'm not sure what to do about this, short of just requiring the use of a SharedAssetDepot - but this would increase the number of necessary code changes to other projects that use CesiumGltf besides the native runtimes.
• The way I've laid out namespaces and usings in SharedAssetDepot.h is almost certainly not compatible with the style guide (I started it before the meeting) so I need to fix that.

[lilleyse]

@azrogers do you think it will be straightforward to extend this approach to also support external schemas (#727) in a follow-up PR?

[azrogers]

@lilleyse I've designed the SharedAssetDepot to support multiple kinds of assets, though only images are implemented in this PR. It should support extending it to also handle loading external schemas.

[kring]

Here are some first comments for you @azrogers. I mostly focused on SharedAssetDepot.h because I think that's the meat of the design, so this isn't a complete review yet. It's looking good! Just a few comments to tighten up the design a bit. In general, I think it would be valuable to really focus on how different things are passed and stored. I think there are some cases where things are copied unnecessarily, and for an ImageCesium that's a very expensive problem. I tried to flag some of these issues, but didn't look exhaustively. If you haven't read it before, Effective Modern C++ has lots of good info about how to decide between r-value references, pass-by-value, etc. (even though it only covers up to C++14).

[azrogers]

@kring Reviewed your changes to cesium-native and cesium-unreal. Both look good, only found a minor typo to fix (which I did myself). Looks like getting all the CI checks to pass is the next step here - anything else remaining before we can get this in?

[kring]

Thanks @azrogers, I plan to merge this today!

[kring]

This looks great, merging!