Display hover-sensitive info in top right corner of toolbar

Nobody has claimed this yet.

I think this would be a nice addition, but I want to gauge interest in/resistance to the idea* before investigating more, since it'd probably be a fairly big undertaking. The concept, as seen from the user's view, is:

- No more "what's this"/explanatory/documentation-esqe tooltips show up
- All info along those lines shows up the dedicated hover-text area
- More hover text can be added now that it has it's own space
- Tooltips are still fine for readouts, like showing dB in the mixer or a control's value

Benefits of a dedicated region over tooltips:

- The top right of the toolbar can display more text than a tooltip without obstructing the user's view
- A dedicated hover-info area can update instantly on hover, whereas a tooltip needs to be delayed
- The top right area of the header is currently unused, and recent mockups in #5261 leave it that way
- Top right is far away from most of the interface, so it's reasonable to avoid placing interactive components there. However, looking is faster than moving the mouse, so it wouldn't be an issue to put something read-only there
- FL Studio and Ableton both do it, and based on my experience with that I think it works well

The concept, from a dev perspective:

- Move the actual text so it's not in a .cpp/.h file, so there's no resistance to adding/lengthening tips because it takes up space in between actual logic.
- A subfolder inside LMMS's install directory should contain files with the contents of each hint. For example, the `Hover Texts` directory might contain `Xpressive.htx`, which contains a hint labeled `PN Knob`.
- Components reference hints by filename and specifier
- Straightforward solution: components manually call a `setHoverText` function when hovered.
- Fairly easy to imagine how this is implemented, some helper class defines the function and updates the hover text area when called
- Might need to manually call a `clearHoverText` so the text goes away when exiting the component's area
- Might need way more event handling in a lot of components that didn't need it before
- Less work for the helper class leaves more work (and potential mistakes to make) for each added hint
- Better (?) solution: components just provide an ID. Another class observes which ID is currently hovered and sets the appropriate text
- Probably a oneliner for each added hint
- Conflicts are resolved in the observing class
- Can't forget to call `clearHoverText` or anything like that

So, as mentioned at the start, are there any objections to something like this? From a UI/UX perspective? What about from a back end perspective? Does it sound like a good/bad idea?

This is a proposal for a dedicated hover-text area in the toolbar and a new way for components to provide hints; no implementation files or tests are named. Start by reviewing the existing toolbar, tooltip, and readout behavior, then clarify the UI/UX and backend approach. Done would require an agreed scope and implementation plan before coding can begin.

Written by the indexing model from the issue text.