Remove unnecessary `readScope` from PlacesStorage

[grigoryk]

All of the 'read' functions that are present in the variants of this class are already 'suspend'. Declaring a specific dispatcher and switching to it is harmless and ensures that we'll always end up doing this work on a dispatchers.io, but all of the consumers are already expected to invoke 'reader' methods on a worker thread (e.g. dispatchers.io). Also, there are no special requirements for reading from places - e.g. it can be done concurrently from different threads.

Contrast this with writing to places - that needs to be sequential, and so we maintain a writeScope to ensure work happens on a single-threaded dispatcher.

So, the read scope is basically an unnecessary overhead and a tiny bit of extra complexity we don't need.

Pull Request checklist

• [ ] Quality: This PR builds and passes detekt/ktlint checks (A pre-push hook is recommended)
• [ ] Tests: This PR includes thorough tests or an explanation of why it does not
• [ ] Changelog: This PR includes a changelog entry or does not need one
• [ ] Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features

After merge

• Milestone: Make sure issues closed by this pull request are added to the milestone of the version currently in development.
• Breaking Changes: If this is a breaking change, please push a draft PR on Reference Browser to address the breaking issues.

[grigoryk]

I'm going to ensure that we're doing the correct thing in Fenix - e.g. never running this code on the main scope.

[mergify[bot]]

This pull request has conflicts when rebasing. Could you fix it @grigoryk? 🙏

[mergify[bot]]

This pull request has conflicts when rebasing. Could you fix it @grigoryk? 🙏

[csadilek]

This was mostly meant as minor clean-up because the readScope isn't necessary, assuming none of our consumers launches these functions on main. However, looking at it again now, I do like that it keeps the implementation symmetric (all suspend functions either run on the dedicated write or read scope) and prevents consumers from mistakenly running this on the main thread. The suspend function should really be good enough to indicate that, but having this fallback also really doesn't introduce any issues. So closing for now. We can revisit.