Migrate local extension storage from localStorage to chrome.storage.local

[astral-sa]

Migrate local extension storage from localStorage to chrome.storage.local

[astral-sa]

WIP List of renames:

• SAARS to generic avatar history lookup
• quickReplyYoutube will need a rename to something like quickReplyPasteAddsTags or something.
• enableMouseMenu to reference the alt toggle option it controls

[astral-sa]

If a user has cookies disabled globally (but enabling them with per-site exception rules), I've found that the extension does not function at all - cookie settings control whether a site, and apparently even an extension, can use localStorage. Another reason to migrate it!

One other thing to plan out is how the default settings will be set. If we unwind the loading logic, we'll need to avoid the situation where the prefs are unset at the time of content script load - or, worse, on Firefox where content scripts are loaded into all existing tabs, we'll need to avoid having all of the content scripts trying to set default settings at the same time. On Legacy SALR, this was handled by the frame scripts (roughly equivalent to a content script) being loaded programmatically into pages by the main script (roughly equivalent to the background page) only after the setting situation was figured out. If all else fails, one possible solution to this is switching content script loading to be programmatically done instead of by the manifest. An advantage there would be to avoid loading content scripts into existing tabs in Firefox. It would also be possible to more easily split up the main content script into a script just for inside threads, a different script just for forum/user control panel view, etc., and only load the relevant script for that page. I'm not 100% on the internals, though, to know if checking the tab URL + programmatically loading the content scripts would be any slower, but I suppose it should still be faster than a round-trip of messages if that's the only other alternative.

Ideally, the content script can check if default settings exist/are up to date, and if so proceed immediately to load itself (nice speedup). Otherwise, it can send a message up to the background script to set the default settings, then continue loading after a slight delay when the background script responds (this case would be roughly equivalent in speed to what we have currently)