Do not handle configuration changes manually

As per the documentation, [it is not recommended to handle configuration changes yourself due to the hidden complexity of handling the configuration changes](https://developer.android.com/guide/topics/resources/runtime-changes#:~:text=It%20is%20not%20recommended%20to%20handle%20configuration%20changes%20yourself%20due%20to%20the%20hidden%20complexity%20of%20handling%20the%20configuration%20changes.). Instead, the app should leave configuration changes to the system, which recreates the activities when the device is rotated or night mode is changed.

Rather than keeping it in activity, to preserve the data or work that is performed in it, it is recommended to use `ViewModel`, a `View`-agnostic object that survives configuration changes and lives as long as the activity (or a fragment) exists. It includes its own `lifecycleScope` that can be used to launch coroutines that are automatically cancelled when the hosting activity (or a fragment) is destroyed. Nifty!

Currently, AnkiDroid uses neither view models nor even retained fragments, instead relying on preserving the activity object. This leads to some obvious issues like #8865 and to some more obscure ones like #10683. It requires hacks in the code. Besides, as some configuration changes, such as theme change, can't be reasonably handled, the activity gets restarted anyway, and since the view restoration logic isn't properly implemented, views may not be properly restored. For instance, card browser keeps position change on device rotation, but not on theme change.

This task can be performed on a per-activity bases. For some activities implementing a proper solution will be a monumental job. But perhaps we can start with some of the smaller activities, or at the very least we can make sure that no *new* activites are handling changes manually.