Android: Use config changed callback for tracking recursive scan setting

[JosJuice]

This way the Settings class doesn't contain a hardcoded reference to a specific setting. And Settings.loadSettings no longer calls getBoolean, which is a step towards fixing the crash when recreating EmulationActivity after process death.

[shuffle2]

what thread does that execute on? it's not fault of this pr, but keep in mind config callbacks are currently totally broken/not thread safe: https://bugs.dolphin-emu.org/issues/13141

[JosJuice]

I'm using new Handler(Looper.getMainLooper()).post in the callback, which ensures that the code will run in the UI thread regardless of what thread the callback was called from.

[lioncash]

Just want to make sure if this is still relevant or needs any changes due to other merged android changes before merging (given it's been 9 months)

[JosJuice]

Yes, it's still relevant. Fixing the fact that config callbacks technically aren't thread safe would be nice, but it's very complex and I consider it out of scope for this PR. This PR doesn't interact with any merged Android PRs as far as I know, but I'll rebase it so we get a check that it still builds and all.

[JosJuice]

The declaration of the callback ID needed changing because of the merge of 7197e3a. Should be good to go now.