Performance: pick from globe depth when possible

### Feature

It's no secret that [globe picking is slow](https://github.com/CesiumGS/cesium/issues/8481). We should soon have some [big improvements](https://github.com/CesiumGS/cesium/pull/9961/files) for globe picking, but for dense terrain data (like ArcGIS), it will still be relatively slow (at least, the first pick on each tile can be slow, but subsequent picks get faster. Still, when panning the camera around, new tiles constantly load in, and cause slight lag as the camera does slow picks to avoid collisions).

It's important to understand the difference between `globe.pick` and `GlobeDepth`. The former uses CPU-side vertex data and intersection tests to find where an arbitrary ray intersects the globe. The latter can be used to do something similar, but via a readback of the GPU globe depth buffer - and, by nature, only works for rays from the camera, not for arbitrary rays.

Now, because `globe.pick` works for arbitrary rays, some code (including the camera class) uses it, when they _actually_ only need the special case of picking along a camera ray. In these cases, it may be wise to read back from the depth buffer instead.

Proposal: allow `globe.pick` to read back from the depth buffer instead of doing CPU-side picking. This could be via a flag, by checking if the input ray is a camera ray (same origin + direction within frustum), or just a new method entirely, to name a few options.

Start by reading the globe.pick and GlobeDepth entry points, then inspect the camera class call sites that only need picking along a camera ray. Compare the CPU-side arbitrary-ray path with the GPU globe depth readback described in the issue. Done means choosing and implementing an approach for camera-ray picks while preserving arbitrary-ray behavior and avoiding regressions.

Written by the indexing model from the issue text.