Fix setting max fps and fps count for renderer

[kiryldz]

Summary of changes

This PR fixes 2 problems that are pretty close to each other.

• when adding FPS listener via MapView.setOnFpsChangedListener previously callback was triggered immediately after render call was executed. That was actually not correct as docs stated that callback should return average amount of rendered frames during last second. Now this is fixed and FPS values are much more readable and reliable. Assuming we use rendering on demand (and not continuous) corner situations are also covered:
  • when not interacting with the map for some time and starting to interact after some delay - we will not report huge amount of missed VSYNC events, instead we will report last FPS update after 50 ms update of map being IDLE and reset counters.
  • when going to background we will also report last FPS update and reset counters so that when resuming the map number of VSYNC missed events will not be huge
• when setting maximum custom FPS via MapView.setMaximumFps correct FPS value will be now applied. Previously without frame pacing algorithm when setting let's say 59 FPS on 60 Hz screen actual FPS was 30 (closest divider). Now we do have basic frame pacing algorithm in place that spreads moments of time when we actually wish to render the frame evenly across one second timeframe.

User impact (optional)

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Optimize code for java consumption (@JvmOverloads, @file:JvmName, etc).
• Add example if relevant.
• Document any changes to public APIs.
• Run make update-api to update generated api files, if there's public API changes, otherwise the verify-api-* CI steps might fail.
• Update CHANGELOG.md or use the label 'skip changelog', otherwise check changelog CI step will fail.
• If this PR is a v10.[version] release branch fix / enhancement, merge it to main firstly and then port to v10.[version] release branch.

Fixes: < Link to related issues that will be fixed by this pull request, if they exist >

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[pengdev]

How about multi-display use cases?

[pengdev]

In a typical Android Auto use case, the MapSurface is not the default display, and does not necessarily have the same refresh rate as the primary display.

[kiryldz]

def worth checking, any ideas how to check this real use-case? we could simulate secondary display (we even have example activity for that) but to properly check it we need diff screen refresh rate on another screen...

[kiryldz]

@pengdev I did not manage to actually simulate primary display with one refresh rate and secondary with another but I did make sure that applying different user refresh rates (via setMaximumFps) to map on primary and secondary displays works fine. Guess that's all we could do now, if some extraordinary case will pop-up (although it's indeed very specific use-case but it should be handled).

Also I did check via our SurfaceActivity that methods mapSurface.setMaximumFps and mapSurface.setOnFpsChangedListener do work as expected.