Face settings: A fairly easy way to store watch face data persistently

[TheOnePerson]

In this PR, I have put together a solution for persisting data of a watch face trying to keep the logic for storing and reading the data files as encapsulated as possible: file_settings.c & file_settings.h implementing two functions face_settings_init() and face_settings_save().

• You can use the face_settings_init() function to initialize the details about the data structure belonging to your particular watch face. The function takes an identifying string for your watch face (must be unique) and a pointer to the data structure that will be saved to flash storage. You can also specify two callback functions (see below). It also checks whether a data file for your watch face already exists and if so, it loads it into the data structure.
• There is also basic logic for dealing with different versions of a watch face and possible changes in data structures. The data scheme version number is used to check if there are data files for previous versions present. If so, the old structure is being loaded to a temporary buffer and the version callback function is invoked, so you have a chance to transfer information from the previous version to the current one. The file belonging to the older data scheme version is erased afterwards (unless you specify otherwise by setting the erase_file variable to false).
• The format of the data files is pretty straightforward: The naming scheme is data_[hash of identifier string]_[data scheme version]. The file's content is a binary copy of the data structure.
• Whenever the watch face wants to persist it’s settings, it can call face_settings_save(). The current settings will only be saved when it’s contents have changed compared to the last call of face_settings_save(). This comparison is done by calculating a (hopefully) unique 4-byte hash value over the content of the data structure.
• Often, it is not feasible to simply write out the whole data structure as it is. For example, if the structure contain temporary properties that do not need to be saved. To handle this, and to further minimize the writing operations you can specify a 'save callback function' that will be invoked right before this hash comparison is done. Within this callback function, you can set irrelevant properties to a default value, so that changes in these properties do not lead to writing out a new data file.

The implementation of persistent storage for the alarm face looks like this:

• add #include "face_settings.h", of course
• in alarm_face_setup() there is only one line added: face_data_init("alarm_face", 0, *context_ptr, sizeof(alarm_state_t), _face_save_data, NULL);
• _face_save_data() is the function dealing with 'cleaning up' the data structure before saving it. It sets some properties to their defaults and looks like this:

  static void _face_save_data(void *context) {
  alarm_state_t *state = (alarm_state_t *)context;
  state->alarm_idx = 0;
  state->alarm_playing_idx = 0;
  state->alarm_quick_ticks = false;
  state->alarm_handled_minute = -1;
  // set all one time alarms to default entries
  for (uint8_t i = 0; i < ALARM_ALARMS; i++) {
      if (state->alarm[i].day == ALARM_DAY_ONE_TIME) {
          state->alarm[i].day = ALARM_DAY_EACH_DAY;
          state->alarm[i].beeps = 5;
          state->alarm[i].pitch = 1;
          state->alarm[i].enabled = false;
          state->alarm[i].minute = 0;
          state->alarm[i].hour = 0;
      }
  }
  }

• finally, the data is being checked for storing every four hours. This is done in alarm_face_wants_background_task() like so: if (now.unit.minute == 0 && (now.unit.hour % 4) == 0) face_data_save(state);
• you could also just put the command face_data_save(state) into your *_face_resign() function, which would lead to immediate saving when the watch face resigns. But since the alarm face had a background-task function anyway, I chose the alternative approach.

This PR also extends the following faces, so that they persist their settings:

• alarm face
• interval face
• invaders face
• time left face
• timer face
• settings face (to save the movement's settings)

Any comments welcome! Let me know if you consider this a feasible approach.

P.S.: I had to heavily alter filesystem.c, too, so that it now uses the browser's localStorage to save and load files. This is due to easier debugging and to get any persistence at all in the emulator.

[TheOnePerson]

Converted this to draft again: I feel like I should simplify the data structure for holding face’s settings details a little bit, thus saving 4 bytes per entry. Will take care of it over the next couple of days.

[TheOnePerson]

I had to make a small change to the preferences face. When the alarm face is present, too, I may happen that the preferences face restores movement's settings after the alarm face has restored its face settings, resulting in blanking out the alarm indicator erroneously. Tbh, the whole construct of persisting movement settings from the preferences face feels a bit dodgy. The cleaner approach would be to move the logic for saving and restoring the data right into movement.c. But I hesitated to change this very central piece of code without feedback from @joeycastillo.