Handle remaining types for property textures in custom shaders

in #10247, I made an initial property textures to cover the common cases of UINT8-based types. However, the [`EXT_structural_metadata` spec](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata#property-textures) allows other types including, but not limited to, the following:

* integer types spread across multiple channels. e.g. a `UINT16` stored as the `RG` channels of a texture. There are some gotchas here, e.g. in WebGL 1, an `int` is represented as a float and there's no `uint` type, so it's not possible to represent a `UINT32` without precision loss. See also `czm_unpackUint()`
* `FLOAT32` encoded in little-endian as `RGBA`. See also `czm_unpackFloat()`.
* `BOOLEAN` types. The spec needs some revisions about the format, but from talking with @lilleyse yesterday, it makes the most sense to store as a `UINT8` value with either `0 - false` or `255 - true`. This way, if you do `bool(texture2D(...).r)`, you'll get the correct value.
* `ENUM` types.
* other weird corner cases that fit in 4 bytes (hopefully we don't have to support all of these?):
* `MAT2` of `UINT8` (technically fits and would probably be column major?)
* array of 2 `VEC2` of `UINT8`

A lot of the details will be similar to #9572, but since textures are a more restrictive format, there are some subtle differences, hence the separate issue.

CC @lilleyse @IanLilleyT

Start by reading the initial implementation in #10247 and the related details in #9572, then review the EXT_structural_metadata property-textures specification. Inspect the existing czm_unpackUint() and czm_unpackFloat() behavior, including WebGL 1 constraints. The issue is complete when the supported remaining texture property types and their encoding rules are defined and implemented.

Written by the indexing model from the issue text.