Deprecate and remove `info.xml`-based `activity`, `settings`, and `collaboration` registrations from `loadApp()`

Summary

AppManager::loadApp() calls getAppInfo() for every loaded app on every request to check for <activity>, <settings>, and <collaboration> entries in info.xml, then routes those registrations to the respective managers. These registrations are just lazy class-name-string registrations -- identical to what apps can already do directly via IActivityManager, ISettingsManager, ICollaboratorSearch, and IAutoCompleteManager in their Application::register() or Application::boot() methods.

There is nothing unique -- from what I can see -- about these registration types compared to others (event listeners, capabilities, search providers, notifiers, etc.) that are already exclusively registered through IBootstrap::register(). The info.xml path is legacy from before the IBootstrap/IRegistrationContext system (NC 20).

https://github.com/nextcloud/server/blob/288964baaa366e4ab60f1f24ebcda94eae94150e/lib/private/App/AppManager.php#L487-L562

Benefits

• Code quality / consistency: One registration mechanism instead of two parallel paths. All registrations become PHP-based, IDE-navigable, and type-checked.
• Marginal overhead reduction (with APCu, ~30 apps): Eliminates ~30× filemtime() stat calls + json_decode() of full app info arrays per request, just to check a few keys that are mostly empty. Negligible in practice, but streamlining is always nice.
• Modest performance improvement (without APCu, ~30 apps): Without a local cache backend, every request does full XML parsing (file_get_contents + simplexml_load_string + array normalization) for every loaded app. Not an ideal deployment configuration, but not uncommon (e.g., shared hosting).

Proposed plan

1. Deprecate the <activity>, <settings>, and <collaboration> registration blocks in info.xml
2. Migrate shipped apps to register via the existing manager APIs in Application::register() or Application::boot()
3. Communicate the deprecation to third-party app developers
4. Remove the getAppInfo() call and associated registration logic from loadApp()
5. Verify no other code in the loadApp() path depends on getAppInfo() being called as a side effect

Start with lib/private/App/AppManager.php around loadApp() lines 487-562, then inspect shipped apps' info.xml registration blocks and their Application::register() or Application::boot() methods. Trace the existing IActivityManager, ISettingsManager, ICollaboratorSearch, and IAutoCompleteManager APIs before planning migrations. Done means the legacy blocks are deprecated, shipped apps use manager APIs, loadApp() no longer performs this registration, and no required side effects are lost.