feature base class poc for standardized separation of concerns using Capabilities class

[diosmosis]

Description:

Adding this base class for three reasons:

• standardizing this practice will make it easier to break apart monolithic parts of the code (eg, making the troubleshooting functions use ajax)
• ajax functionality is not well handled currently (ajax handlers must always be added, even if a feature should not add other hooks)
• the code that initializes the different feature classes is currently rather unwieldy. the use of a standardized api will simplify it.

This refactor will be done piecemeal.

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[textagroup]

@diosmosis Running a AI review found the following

• Findings:

1. High: safe mode no longer short-circuits most plugin initialization, which defeats the purpose of MATOMO_SAFE_MODE. In develop, the constructor returned immediately after wiring only Admin(...,
   false) and SafeModeMenu (classes/WpMatomo.php on develop, lines 60-67). On this branch, the safe-mode check is folded into init_features(), but the constructor continues registering non-safe-mode
   hooks afterward (classes/WpMatomo.php:57, especially lines 66-91). That means AdBlockDetector, WhatsNewNotifications, AIBotTracking, TrackingSettings::register_ajax(), and
   GetStarted::register_hooks() still run in safe mode. If safe mode is being used to recover from a broken feature load, this branch can still execute unrelated code and reintroduce the failure path.
2. Medium: the Get Started page’s marketplace step is broken after the MarketplaceSetupWizard refactor. GetStarted::show() still just instantiates MarketplaceSetupWizard and renders its body (classes/
   WpMatomo/Admin/GetStarted.php:65, lines 72-73), but the wizard no longer registers scripts in its constructor. Script enqueueing now only happens through register_hooks() (classes/WpMatomo/Admin/
   MarketplaceSetupWizard.php:48, lines 48-68) and only when the feature is active on the marketplace install/subscriptions tabs (classes/WpMatomo/Admin/MarketplaceSetupWizard.php:20, lines 20-35). On
   the Get Started page, step 3 still renders the “Go to plugins admin” / “Activate” UI, but marketplace_setup_wizard.js and mtmMarketplaceWizardAjax are no longer loaded, so the polling/activation
   flow there stops working.

[diosmosis]

@textagroup AI findings should be fixed, but i haven't manually tested just yet

[diosmosis]

@textagroup was able to test now, issues are fixed.