Use '#config_target' in the settings forms

Problem/Motivation

Part of the plan in #3565209: [Meta] Drop support for Drupal 10.2 and below: Use config_target for forms.

The settings forms of Admin Toolbar, Admin Toolbar Tools and Admin Toolbar Search still use the legacy pattern of ConfigFormBase: each form reads its values with $this->config() to set #default_value, declares getEditableConfigNames() and copies each submitted value to the configuration by hand in submitForm().

Since Drupal 10.2, the #config_target form element key makes Drupal load the default values, save the submitted values and validate them against the configuration schema. The configuration schemas of the three modules are already fully validatable (#3570717: Make configuration schema fully validatable), but the forms do not benefit from it.

Steps to reproduce

Review the form classes:

• src/Form/AdminToolbarSettingsForm.php
• admin_toolbar_tools/src/Form/AdminToolbarToolsSettingsForm.php
• admin_toolbar_search/src/Form/AdminToolbarSearchSettingsForm.php

Proposed resolution

• Add #config_target to each form element and remove the #default_value properties and the manual saving in submitForm().
• Use core's RedundantEditableConfigNamesTrait instead of getEditableConfigNames().
• Use the Range constraints of the schema for the limits of the Menu depth and Maximum number of bundle sub-menus fields, so the form and the schema have a single source of truth.
• Cast the hoverIntent timeout to an integer with a ConfigTarget (toConfig), since the select element returns a string and the schema expects an integer.
• Keep the labels and descriptions in $this->t() in the forms, so the existing translations still apply.
• Add an update hook setting sticky_behavior to enabled if it does not exist: it was added without an update hook, and the setting is now required by the schema and the form.
• Add and update tests to check the saved values and their types.

Remaining tasks

• Review.
• Once the Drupal 12 issue (#3594696) is merged, add the PHPUnit attributes to the new test (#[Group], #[RunTestsInSeparateProcesses]) if needed.

User interface changes

None, the forms look the same. Submitted values are now validated with the configuration schema, so an invalid value is reported as a form error.

API changes

None. The form classes no longer define getEditableConfigNames(), which is provided by RedundantEditableConfigNamesTrait.

Data model changes

None. The update hook admin_toolbar_update_8007() only adds the sticky_behavior: enabled setting, if it is missing.