Settings improvements

[toasted-nutbread]

As the number of features Yomichan has has grown, so too has the number of settings. Some of the settings are more complex and require more logic than just a simple HTML input field to adjust. As such, new scripts have been added to control the more advanced behaviour. Such features currently include:

• Anki template preview & validation
• Storage settings and information
• Dictionary list
• Multiple audio playback sources
• Popup preview
• Profiles and conditions

In order to simplify development of future settings and the corresponding UI, there are a few tasks that have come up which could improve the workflow:

• [x] Make all the existing settings controls more modular. This will initially include splitting the settings.js file up into multiple files.
• [x] Following the above, the dependency coupling between files should be reduced to be unidirectional rather than bidirectional. This should make the code easier to understand without having to jump back and forth between two (or more) files.
• [x] Make it more explicit when a mutable reference to the options object is being used. #306
• [x] Add support for a validation schema for settings. See: https://json-schema.org/. Settings are currently not validated, so invalid values can be typed into the input fields and they will be saved, which can cause Yomichan to misbehave. #310
• [x] Enforce schema validation on all settings changes. This can be done using Javascript's proxy system.
• [x] Have a common system for assigning settings which can be used from both the frontend and backend. Make this system the only method for assigning settings. I.e. the settings page will not have any direct references to the backend's options object. Instead, only copies should be passed around, and assignments/updates should use the API calls. This will primarily involve a refactoring of apiOptionsSet.
• [x] Simplify how settings inputs are declared in the settings HTML/JS pages. Adding a new input for a simple setting (boolean, string, etc.) currently requires adjustments in at least three places: settings.html, settings.js/formRead, and settings.js/formWrite. This can be streamlined to just having to update the HTML. #335
• [x] Add support for importing/exporting settings. #112, #311
• [x] Add quick navigation links to settings page. #319
• [x] Add improved descriptions to the settings page.

[toasted-nutbread]

For reference, I have currently started on most if not all of these tasks. The first one is taken care of by 403b86675d288a8082125475f87f9b1740e3480a...767a480a847b641768b94b835a6ac10c1c3d69bf, which is just moving code around.

The remaining tasks are all somewhat intertwined, so fully implementing them will take a bit longer. I will put up a pull request for it when it is completed.

[siikamiika]

Have a common system for assigning settings which can be used from both the frontend and backend. Make this system the only method for assigning settings. I.e. the settings page will not have any direct references to the backend's options object. Instead, only copies should be passed around, and assignments/updates should use the API calls. This will primarily involve a refactoring of apiOptionsSet.

One thing I noticed when using apiOptionsSet in search page query parser was that await apiOptionsSet(...) didn't wait for the options to propagate back to DisplaySearch, and accessing the local copy of the options on the next line gave the previous value. I'm not sure how feasible it would be to wait for everything to call apiOptionsGet before resolving the promise.