Improve OpenLibrary's User Interface to make librarians work easier

There are countless small things that annoy me when working with the web interface of OpenLibrary. While none of them itself is a major problem, in sum they hinder my workflow and prevent me from using the features OpenLibrary offers.

(To translate this into something developers can more easily relate too: Imagine you had to work on a complex programming task with what AmigaOS had onboard in the early 1990s. Yeah, you can do it, but you'd definitely rather use your modern programming environment with its comfort features like syntax highlighting and such.)

### Tasks that belong to this epic issue

#### Editing Convenience
- [x] #7308
- [ ] #7309
- [x] #4548
- [x] #7055
- [x] #7313
- [x] #3523
- [ ] #7319
- [ ] #7320
- [ ] #7325

#### Layout and Design
- [x] #7259
- [ ] #7314

#### Identifier List
- [x] #6108
- [x] #7030
- [ ] #7315

### Describe the problem that you'd like solved

**1. A preview feature for all changes**
At the moment, many changes can only be reviewed by saving the page, and then having to reload it to correct any mistakes. Whiles that save, load and return to last edited field routine takes just a couple second per edit, a well described book with a lot of metadata requires often several reloads to get everything right. The additional time makes me pause whether really to correct that tiny mistake I recognized late when I already edited fifty editions that day.

**2. Proper WYSIWG features for flow text fields**
There is a bare bone formatting help for the "How would you describe this book?", but I never use it. Instead, I just dump pure text in and call it a day. When it comes to Table of Contents, I do not have the slightest idea what to expect and simply throw text in and pray that St Isidore of Seville intercedes on my behalf.

**3. More clearly organized edit books page**
When editing a book, I am constantly searching for the correct field to enter data and scroll up and down a lot. A more concise layout would help.

This is similar to the work of our UX/UI experts Dana and Samuel on the patron interface: Their tweaks seem really minor, almost invisible, but they still required a lot of effort and the users truly appreciated the changes because they now find features more easily.

**4. The ID numbers list needs to be sorted and cleaned**
The list with ID Numbers is really long, and whenever I want to enter an ID I have to scroll up and down that list a lot. Some entries are duplicates, some do not work at all, others are unclear which of the institutions identifiers is requested.

Most librarians specialize on a certain topic in their work, and thus need specific IDs a lot. (For example, I mainly work with German books and thus need the Deutsche Nationalbibliothek on almost every edition.) It would be great if those could be "pinned" on an individual base at the top of the list instead of the static order. (Even better if they would be automatically pinned according to ID number usage statistics.)

**5. Documentation needs Integrated Document Management**
It is extremely difficult and time consuming to keep the documentation up to date, you basically have to write HTML in a very sluggish plain text editor. It also misses any support to find errors, for example a _broken link checker_. It is also not easily accessible (no "need help" prompt at the place I work, I have to manually go to another part of the website), and sometimes rather difficult to find the answer you are looking for.

This leads to an increase in support requests, which take even more time from maintaining the documentation - and only someone who knows both the working of OpenLibrary and common support requests for different topics can write a proper documentation.

**6. Tools to manage large amounts of editions**
Some author's have very many reprints and translation of their works - at the moment, _Harry Potter and the Philosopher's Stone_ has 303 editions in 46 languages, for example. It is basically impossible to work through this amount of editions to correct the metadata manually, as there is no way to fix the sorting order, filter within the editions or to mark an edition as "done". (Or at least I am not aware of any, in which case this highlights point 5).

### Proposal & Constraints

1. Both Overleaf and Wikipedia offer such a page preview
2. There are several FLOSS Online rich-text editors that can be integrated in websites, for example Trix, TinyMCE or CKEditor.
3. Dana and Samuel are already doing that in other parts of the page.
4. This should basically be an Adaptive sort.
5. There are some FLOSS information management platforms, but I am not well versed in them.
6. I do not have the slightest idea how to resolve this, I just know that I would not even attempt this task at the moment.

I am fully aware that this is a monumental task which cannot be solved in one go, but has to be taken step by step and probably has to be split in several smaller issues. Some parts might be impossible to resolve at all. I still think it worthwhile to gather this information in one place, because while any of the issues itself is minor, the combination makes them noticeable.

### Additional context

There were already several issues that describe part of this more encompassing request:
#705
#866
#1825
#3328
#4480
#5349
#7151
#7259

### Stakeholders

Start by reviewing the linked issues and the unchecked tasks under Editing Convenience, Layout and Design, and Identifier List. Split this epic into focused issues for the edit-book page, identifier list, documentation tools, and edition management; each resulting issue should identify a concrete change and a verifiable completion condition.

Written by the indexing model from the issue text.