ModuleView: only give ScrollArea focus if its useful

ModuleView places the loaded kcm in a QScrollArea so that it becomes scrollable in case it is larger than the window size. This QScrollArea takes keyboard focus. This is necessary to allow the user to pan the view useing the keyboard, but is a completely useless tab focus chain entry in the majority of cases, namely when either a qml kcm is loaded (where the scrollability is usually handled with a ScrollView, as in the components from KCMUtils), and whenever the viewport is large enough to fit the whole kcm. To the user, this feels like focus vanishing into thin air, as it lands on an element that cannot be interacted with at all.

This change sets the QScrollArea to NoFocus if the content fits, and only allows tab focus if it does not.

---

Test Plan:

1. Start System Settings (landing page)
2. Press tab multiple times.
3. (without patch) Focus order goes: (Start) Search bar > Hamburger Button > apparently nothing? > apparently nothing? > Breeze global theme image button thing.
4. (with patch) Focus order goes: (Start) Search bar > Hamburger Button > apparently nothing? > Breeze global theme image button thing.

Notes:

1. This breaks focus handling in qml without a patch to kcmutils/kcmoduleqml. And that patch breaks kcmshell6 without doing the equivalent to this MR to kcmoduleloader. So if we go for this, we'll have to coordinate the changes. See also Note 5 and 4. [ETA] it might not actually require that patch strictly speaking, as it might be broken in master generally, but that patch seems to fix it. Investigating. This is a preexisting issue that can be fixed with either frameworks/kcmutils!250 (closed) or frameworks/kcmutils!253 (merged)
2. Focus still lands once on apparently nothing. That's not actually nothing, it's just landing on the sidebar ListView, where you can't see active keyboard focus on the active item. Breeze theme issue; we could also consider reworking sidebar keyboard focus, tabbing from sidebar header to sidebar listview seems a bit unnecessary because you can just use the arrow keys (but may be required for a11y discoverability?). But 50% less apparently nothings are still an improvement in my eyes.
3. Orca still does not read out the first item once focus lands on it. I think I have a vague idea why, but might be wrong and have no idea how to fix it The above patches also fix that.
4. Focus handling in this kind of mixed widgets/qml application is extremely fragile. In the ones I've tried this has consistently made things better and never worse, but I haven't tried everything. It's possible something else breaks now.
5. Orca reads out the full context after each form entry. I think I know what's wrong, and if I'm right it's an upstream Qt issue that we can't fix. I'm still working on confirming my hunch.
6. I have no idea what I'm doing, there may be a better way to implement this.