Course settings: plugin sections are hardcoded one by one in CourseSettingsManager

[AngelFQC]

Problem

In 1.11.x any plugin could inject its own block into the course settings form just by declaring $this->course_settings in its plugin class. AppPlugin::add_course_settings_form() iterated over every installed plugin and rendered those blocks generically — the core knew nothing about individual plugins.

That mechanism is gone in 2.0. CourseSettingsManager (src/CoreBundle/State/CourseSettings/CourseSettingsManager.php) hardcodes one if per plugin, in both getIntegrations() and buildSections():

if (!empty($integrations['lti']['enabled'])) { ... }
if (!empty($integrations['courseBlock']['enabled'])) { ... }
if (!empty($integrations['courseHomeNotify']['enabled'])) { ... }
if (!empty($integrations['courseLegal']['enabled'])) { ... }
if (!empty($integrations['customCertificate']['enabled'])) { ... }
if (!empty($integrations['buyCourses']['enabled'])) { ... }

Consequences:

• A third-party plugin that declares course_settings renders nowhere. The feature only exists for the handful of plugins the core happens to know about.
• Every new plugin needing course settings requires a patch inside CoreBundle.
• The core references plugin names as string literals, so CourseSettingsManager has to be kept in sync with public/plugin/ by hand.

Proposal

Restore the 1.11.x capability, but with a Symfony-native design rather than the legacy FormValidator-driven one: an interface implemented by each plugin (collected as a tagged service) that returns a course-settings section descriptor, which CourseSettingsManager gathers and serializes into the sections payload the Vue form already consumes.

The six hardcoded blocks above then become plugin-provided instead of core-provided, and CoreBundle stops naming plugins.