Extension logging

[wirednkod]

This PR covers all-but-one (the last) bullets of Pierre's comment in issue #429 .

Some details

Don't output the logs in the console, but instead keep the logs in some buffer. Only the last ~500 or so lines should to be kept, otherwise our memory usage would continue increasing forever.

I left the info logs to still appear in the console. 1000 lines are kept in memory and shown in the extension's Option page.

Add a semi-hidden way somewhere in the extension that can display these logs. The average Joe doesn't need to know that these logs exist, it's more for developers to be able to understand problems.

The semi-hidden way for now is another tab in the Options page. This will be adjusted in the next UI upgrade from @Goranch3

(maybe) If the ~500 log lines that we keep contain a warning or error, there should be some indication. Again, the average Joe doesn't need to see this, but for developers it's useful to be able to easily see if a warning or error has happened. Warnings or errors are generally bugs in smoldot that should be fixed, but don't necessarily prevent applications from working normally.

2 placeholders are keeping separate from rotating debug logs, the errors and warnings. Even though only 1000 latest lines are are kept from debug logs and then older ones are dissappearing, warning and errors are kept.

Last bullet of Pierre's comment will be addressed in different PR.

A screenshot on the UI perspective can be seen below:

[tomaka]

Logs only make sense if they're in the correct context.
Please don't split debug, info, warn and error logs in different windows, they should all keep the order they came in

[wirednkod]

Logs only make sense if they're in the correct context.
Please don't split debug, info, warn and error logs in different windows, they should all keep the order they came in

In debug list all errors are kept there (i should probably alter the name from "debug" to "all logs" or something). The errors and warns are kept in separate lists in addition, in order to be able to identify them faster. In addition errors and warns do not disappear once the 1000 lines pass. This way even if not identified when it happened, dev can know that something happened, see the warn/error log even out of context at a later time. Initial idea was just a counter, but then i thought that once error rotates away:
a) its not easy to track that it rotated away, so that counter will be reduced when it does
B) dev will not know that something happened if does not see it (even after rotation) in the logs

[tomaka]

Mostly good!