[chore] Restructure developer docs

What do we need to do?

When we started the devdocs we tried to consider to structure our existing content better.

We have, largely speaking, achieved that. However, the current structure is still somewhat confusing.

flowchart TD
    C[Versioned documentation]
    C --> GUIDES[Developer Guides]
    C --> API[API Guides]
    API --> FILES[Common files]
    API --> CORE[Core APIs]
    API --> PLUGIN[Plugin Types]
    API --> SUBSYSTEM[Subsystems]
    C --> DEVUP[Developer Updates]

Within each of API guide sections we have a fairly large list of APIs and information, and it isn't always clear which location docs should be in. For example, the Output API documentation which covers critical methods such as {{format_string}}, and {{format_text}} are under Subsystems, but arguably these shoudl be uder "Core APIs". For most people APIs such as these subsystem APIs are so critical to the daily development of Moodle that their categorisation as a subsystem is confusing when compared to a subsystem such as Task, Editor, Privacy, Check, Availability, etc.

I think we need to find a way to reduce these restructure some of these categories, and perhaps toimprove our "Developer guides" too.

Many of the se Core API and Subsystem docs would be better served as guides. It is not in our interest to store API documentation in any static form with function signatures in these docs. We should find better ways to link to the live documentation instead.

Start by reviewing the versioned documentation structure, especially Developer Guides, Core APIs, Plugin Types, and Subsystems. Compare where APIs such as Output, including format_string and format_text, are currently documented and identify how they should be reorganized. Done means an agreed structure with clearer guides and links to live documentation rather than static function signatures.