perf: improve MarkerComposable rendering performance

[brucemok8]

Summary

This PR improves the rendering performance of MarkerComposable, particularly when displaying a larger number of markers with frequently updating content.

Changes

• Reuse ComposeView instances instead of creating and disposing them for each render. The view is retained and used to generate updated bitmaps when marker keys change, and disposed only when the marker is removed.
• Update rememberComposeBitmapDescriptor to return a nullable type. Callers skip rendering until the bitmap is ready, preventing main thread blocking and allowing markers to appear asynchronously.

Impact

These changes significantly reduce UI jank during marker updates. In testing, scenarios with ~25 dynamically updating markers show noticeably smoother performance.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[LoyalAbbas]

LGTM

[kikoso]

@brucemok8 , I am not convinced about this approach. The ComposeView is now kept alive and attached to host (the window root view) for the entire lifetime of the marker, only removed when the marker leaves composition. Even with setting alpha to 0, views with alpha = 0f are still part of the root's measure/layout pass and are typically still touchable/hit-testable by default in Android.

Also, since icon starts null and MarkerImpl is only composed once it's non-null, markers will now pop in a frame or two late instead of appearing immediately.

[kikoso]

And another thought: there might be a potential race between content recomposition and bitmap capture. setContent { currentContent() } is only called once (inside DisposableEffect(host)), and relies on the nested composition's own recomposition (driven by state reads inside currentContent()) happening before LaunchedEffect(*keys) fires the actual draw()/bitmap capture. In the common case where the same state change drives both the content and the keys, this should resolve within the same recomposition pass since it shares the same CompositionContext/Recomposer.