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

[gino-m]

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

• class MapViewModel
  • exposes source-of-truth states (CameraPosition) as StateFlows or LiveDatas
  • exposes map events as ShareFlows
• 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