The current course editor action menus still rely on some 3.9 global functions, use old coding style and namespace, and have some inherited code smells.

The old course editing will be deprecated in 5.0, so we need to replace parts of the code. This issue prepares the class for the deprecation of any course format incompatible with components. More specific:

• The old spaghetti code functions will be renamed as legacy and used with 3.9 course formats (until it's final deprecation on 6.0).
• All classes will use the correct namespaces and not the aliases (the issue is part of a cleanup epic, so cleaning it up seems the proper thing to do).
• Replace any use of the old 3.9 logic for internal output methods.
• Split the logic into maintainable methods (the current ones are 150+ lines of code each).
• Add some deprecation messages to alert old formats.

Also, the permalink option should be moved before the delete one because the current position is wrong.

Technical shaping

The current course editor action menus are implemented in 5 classes:

• core_courseformat\output\local\content\section\controlmenu is still a copy of the old section_control_items from the course/renderer.php.
• core_courseformat\output\local\content\cm\controlmenu  is still using the old course_get_cm_edit_actions
• core_courseformat\output\local\content\cm\delegatedcontrolmenu has a merged copy of section_control_items and course_get_cm_edit_actions
• format_topics\output\courseformat\content\section\controlmenu adds the highlight topics option but it is implemented like the old section_control_items

We cannot get rid of the old action menu until 6.0. However, the new refactor should not include all the twisted logic required for old formats. The process should be:

1. Move all the previous logic to a section_control_items_legacy method. The method will have a TODO note for the final deprecation.
2. Refactor the rest of the class as much as needed.
3. In the refactored section_control_items and get_action_menu add an if clause for the courses that need the legacy one (!$this->format->supports_components()).

This is the safest approach and will guarantee old formats will continue working until the final deprecation without adding unnecessary complexity to the refactor.