Improve feature discoverability in the documentation

[Reinmar]

This epic is about improving the Features guides to make them:

• Present the features better and in more real-life scenarios.
• Give more context about what the feature can give you, where and how it can be used.
• Cross-linked to other similar/related features.
• Cover the needs of both non-technical people who research what they can achieve with CKEditor 5 and more advanced technical users who need to know how to install, configure and customize the features.
• Have a common structure that is logical, familiar and easy to browse.

Proposed feature guide structure

1. Intro section, with some background, context, basic feature explanation.
   1. If the feature is commercial, it a beta, experimental, it should be mentioned here, too.
2. Related features - referencing similar features or features that can be used in the same context.
3. Demo - that should cover the most full-blown or the most commonly used version of the feature (image guide!).
4. Detailed feature information.
5. Configuration.
6. Installation.
7. Common API.
8. Contribute.

TODO

This is a huge task and it will not be covered in one iteration. Some sub-tasks that could be a part of this epic:

• Create/revamp a features overview landing page in the documentation. Could the overview group the features somehow
  • Create a list of all available end-user features (Create a list of all end-user features #5702)
  • How to mention sub-features (as in features that are a part of a feature and could thus be hidden)?
• Rethink which toolbar buttons are available in a given snippet. Should it be more like in a "natural" editing scenario, or should the focus be on a particular feature that is described?
• Make it clear that editor samples in the docs are demos (Make it clear that editor samples in the docs are demos #1188)
• Sample with all features ([Docs] Sample with full features set #5588)
• Mark UI buttons in the guides to improve discoverability (Mark UI buttons in the guides to improve discoverability #6267)

[Reinmar]

cc @panr

[godai78]

This is planned next (already started to be introduced): #7924 so this will also nicely cover this: #5721

[godai78]

Stuff done:
* new demos for paste from word and paste from gdocs: #8349 
* adding Markdown output to "related" (step 1): cksource/ckeditor5-internal#411
* new Markdown demo: #8336
* adding and expanding "related features block" in a number of PRs: #8250

[godai78]

How are we doing with the "new" / "extended" flag for the guides? This would also help draw attention to some features.

[godai78]

I allowed myself to change the propose feature guide structure reflecting changes that are already introduced into a large number of the guides.

[godai78]

We should revisit the #5588 idea for "all-features editor" (as far as this is available, OFC) and decide whether we put it in examples or on the features landing page.

[godai78]

Also, this is a rather new implementation and an approach we should consider. This is the online html editor user-guide, which is user oriented, without any developer stuff: https://onlinehtmleditor.dev/user-guides/real-time-collaboration-editor/

We may consider expanding all docs with this kind of approach of: an introduction (existing) - user guide (to do) - developer info (existing) scheme, which would make it:

• more user friendly,
• prolly more discoverable (also sales-wise).

It would be a massive task, but parts of these are already written if we repurpose the existing guide and anyway this does not need to be a mammoth update, but can be introduced gradually (and also during other commits, as well).

Your opinions welcome. The job is partly done anyway for other purpose, so you can see and test it in real-life scenario (please disregard the CKE4 editor, tho).