New mechanism for project settings

[svetter]

Store an arbitrary number of settings by using just one string column in the settings table, with a string column identifying what setting it is. A table in code then lists and reserves the key for every single setting, or a number of consecutive keys for a collection of settings.

Needs functions to encode to and decode from string from/to various data types.

Also needs a new mechanism to update the database structure to new versions (to get rid of the old table and create a new one), and to block incompatible versions from opening.

This will enable storing all implicit settings where it makes the most sense - in the system or the database, that is, as global implicit settings or as project-specific implicit settings, without the need for a new column in the project settings table, which is obviously not a good usage of a table, especially when settings have different amounts of values. E.g., column widths can then be stored per project, which makes more sense.

• Adapt SettingsTable and ProjectSettings classes to use only one column and store/load project settings by key
  • Use string column for the identifying keys (mimicking global settings via QSettings)
• Create a method to store a generic project setting
• Create a method to load a generic project setting
• Create methods to encode and store project settings of various types
• Create methods to load and decode project settings of various types
• Create the table of project settings, where single or grouped settings are mapped to keys
  • Store app version as the first setting
• Create project settings update mechanism which deletes the old table and creates the new one
  • Make the update process explicit by prompting the user to greenlight it
  • Transfer default hiker, filters can be discarded
• Show warning when opening database with newer version than app

Implementing uses for this more convenient mechanism can be done after this issue is completed.