perf: Make CameraPositionState and MarkerState stable

[DSteve595]

CameraPositionState has a few unstable properties. Rather than verify all usages of these are safe for stability, I'm opting to back them with mutable states, so the compiler can mark the class stable for us.
MarkerState's internal var: Marker? property was causing the class to be marked unstable.
While I think it can safely be marked @Stable as-is, I'd rather have the compiler infer that. I feel better backing it with an actual state value, that way if we later do an actual non-imperative state read it won't break stuff.

Verified stability via compiler report.

Fixes #232 🦕

[googlemaps-bot]

🎉 This PR is included in version 2.8.1 🎉

The release is available on:

• v2.8.1
• GitHub release

Your semantic-release bot 📦🚀

[bubenheimer]

Nervous about seeing additional state added to MarkerState: an app may have quite a lot of Marker/MarkerState objects. Were time/space performance impacts considered?

[DSteve595]

@bubenheimer No, those weren't considered. A benchmark would be useful. I made the judgment call that stability of a State class is generally expected, and so ours should fit the pattern.
Have you encountered any performance issues from this?

[bubenheimer]

The Marker-related change looks like a red flag to me. Marker is a mutable type inside what's now a MutableState. And on top of that there is MarkerState.position, which replicates parts of the MutableState-wrapped mutable object inside another MutableState.

As you may be aware, I believe that MarkerState can and should be eliminated entirely, at least from the public API surface: #149

[DSteve595]

I'm gonna take some time to digest your thoughts in #149. Thanks very much for the detailed explanations.

The MarkerState changes were made with defensive correctness in mind (I'm not positive about enumerating all cases that can modify those properties, now and in the future). I'm inclined to try benchmarking some scenarios.