Refactor view model logic out of `MapView` and simplify view/VM class hierarchy

The proposal is the have the following Maps SDK agnostic classes:

* class MapViewModel
* exposes source-of-truth states (CameraPosition) as `StateFlow`s or `LiveData`s
* exposes map events as `ShareFlow`s
* interface MapView
* exposes getViewModel() through which the app interacts with the map

And a concrete implementation as now:

* class GoogleMapsMapFragment: MapView
* observes states in MapViewModel and syncs map fragment
* binds events callbacks to callbacks in MapViewModel

Example flows might look like:

1. fragment observes cameraPosition LiveData, sync UI state on change
2. user drags map -> fragment onCameraMoved() -> vm.onCameraMoved() -> update vm.cameraPosition
* 1 gets triggered, but does nothing since new position == old position
3. user taps cluster -> vm.animateTo(cameraPosition) -> emits pos from vm.animateCameraRequests -> fragment animates -> path in 2 is triggered, camera position state is updated

@shobhitagarwal1612 @JSunde FYI