osltoy: Requested editor improvements

[silvialpz]

Description

• Font in the yellow highlighted line will always be black, this improves readability in dark mode
• Tab size is now set to 4 characters wide (a request I saw in Meta-issue: osltoy features and fixes #1862 )
  • This required a small modification to char_width_pixels() to use fixedFont() for QFontMetrics. I'm not sure what font it was using previously, but it was wider than the font that showed up in the editor. This change allows me to reuse the function for the tab distance.
  • A side effect is that line number area is now slightly narrower. Let me know if it doesn't look right.

Tests

Only using visual verification for the UI changes.

Before	After

Checklist:

• I have read the contribution guidelines.
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
• My code follows the prevailing code style of this project. If I haven't
  already run clang-format v17 before submitting, I definitely will look at
  the CI test that runs clang-format and fix anything that it highlights as
  being nonconforming.

[lgritz]

The fix for the highlight color is perfect, thanks!

I'm less sure about the tab. I that what you have is still adding an actual TAB character in the text of the file, and you are merely adjusting how much horizontal space is advanced for a tab character, in the Qt-based editor. But if you open the saved file in any other editor, a tab is a tab, and it will generally be 8-stop and therefore look different than it did in the osltoy window.

I think that there is a subtle distinction to make between (a) what a TAB character in the file means, and (b) what happens when you hit the TAB key in the osltoy editor window.

As for (a), since almost all editors will consider tab characters to align to the next 8-stop, we should do that, too, in order for osltoy to display files authored elsewhere correctly, and vice versa.

As for (b), I think there are a few sensible choices:

1. Old behavior -- tab key adds a tab character, which advances to the next 8-stop. Unexciting, but also consistent.
2. Tab key converts to the appropriate number of spaces, or spaces+tabs, to get to the next stop, which should certainly default to 8, though maybe allow customization for people who prefer 4-indentation like I do.
3. Fancier: tab key advances to the indentation level of the previous line. This still leaves one free choice: does it do this by adding spaces or actual tab characters? (See 1 and 2 above.)

If you want, I'm ok with you modifying this PR to ONLY tackle the highlight issue and leaving the tabs for another day / another PR, and possibly some consultation to see what other onlookers would prefer in the specific behavior.

One thing I do not know is if the Qt editor widget already accounts for these choice and has a way to select them without having to write the logic ourselves.

[silvialpz]

Okayyyy, I see the difference between tabs and spaces now. I'm leaving this PR only for the highlighted text change.

Looking at the way VS Code does it would be a way to go? It shows the spaces for the tab size along the bottom bar and when clicking it gives you these options: