I3S Support

[cesiumjs](https://github.com/CesiumGS/cesium) supports the [Esri I3S Specification](https://github.com/Esri/i3s-spec). I3S is one of the other large-scale geospatial LOD streaming formats.

My proposal is to add an `I3STilesetLoader` under `Cesium3DTilesSelection` following the same pattern as other tileset loaders in the repo. If there is any interst, I am happy to make a PR but I have a question. I3S supports any arbitrary CRS while 3D Tiles only supports ECEF. Most I3S files are in 4326 which is no problem. But how would the maintainers like me to handle CRS that would require the `proj` library? Throw an exception? Return an error Result?

To the same point, I3S uses slpk for the local file format which is an uncompressed zip archive. Would there be any appetite for adding an `ArchiveAssetAccessor` alongside `Curl`? The 3D Tiles spec also allows for `.3tz` which is an uncompressed zip file so this would round out the default Asset Accessor implementations for common 3D Tiles formats.

Start by reading the existing tileset loaders under Cesium3DTilesSelection and the Curl asset accessor to understand the proposed I3STilesetLoader and ArchiveAssetAccessor patterns. Before coding, resolve the maintainer decision for arbitrary CRS handling with proj and slpk/.3tz archive support; done means an agreed scope is implemented with tests.

Written by the indexing model from the issue text.