True Orthographic View / Orthographic Camera support when tilt is zero

**Is your feature request related to a problem? Please describe.**
Yes, at a tilt of 0 (a completely flat, top-down map viewing angle), the library forces its internal THREE.PerspectiveCamera matrix onto the layer.Because it enforces a perspective projection, now when we pan from the center say, for eg. I added a 3d model (cuboid) with significant height (~15m) I start to see the walls/sides of the cuboid, which isn't ideal in topdown view

**Describe the solution you'd like**
I would like an option to explicitly support an Orthographic View mode, or a clean mechanism to toggle/provide a THREE.OrthographicCamera to the ThreeJSOverlayView wrapper.Ideally, when the map is at a tilt of 0, the library should either:Allow developers to pass a custom camera instance (e.g., THREE.OrthographicCamera) to the config options.Flatten the perspective divide components of the camera's projection matrix automatically if a flat orthographic mode boolean flag is toggled on.

**Describe alternatives you've considered**

1. **Mutating the perspective camera's projection matrix direct**: After transformer.fromLatLngAltitude() sets the combined MVP matrix on the internal PerspectiveCamera, we tried zeroing out the perspective-divide components to flatten it into an orthographic-like projection. This breaks the library's internal pixelToLatLng → latLngToVector3 coordinate pipeline, causing vertex/marker placement to drift or fail entirely.
2. **Creating a separate THREE.OrthographicCamera and rendering the scene with it**: We successfully worked around the issue by subclassing ThreeJSOverlayView, overriding onDraw() to still set the perspective camera's matrix from the transformer (keeping internal coordinate conversions intact), but rendering the scene with a standalone OrthographicCamera whose frustum is derived from viewport dimensions and the Mercator meters-per-pixel at the current zoom/lat. We also had to override raycasting to use setFromCamera(ndc, orthoCamera) for correct parallel-ray intersection. This works, but it's fragile and has other side-effects, it depends on internal implementation details of the library (the onDraw signature, camera access, transformer behavior) that could break with any update.
3. **Overrode the WebGL onDraw** frame step. Every frame, immediately after Google sets up the camera matrix but just before rendering the scene, we modify the camera's underlying array:
We **zero out the entire last row of the column-major matrix**: elements[3] = 0.0, elements[7] = 0.0, elements[11] = 0.0, and set elements[15] = 1.0. This alternative was very clean.
**Additional context**
Our workaround, alternative 2. (separate ortho camera rendered alongside the library's internal perspective camera) also introduces visual jitter / lag during pan and zoom for the 3d model objects in the overlay scene added.