Startup tasks

Describe the feature
There are times, based on a model or Change adjustment that we want to trigger snapshots to regenerate. This would be used for example when #1948 is fixed.

Design

New un-synced table (like ProjectData) called StartupTasks it might look something like this:

with a C# class like this:

public record StartupTask(StartupTaskType Task, DateTimeOffset? ExecutedOn, DateTimeOffset CreatedOn);
public enum StartupTaskType {
  unknown,
  regenerateSnapshots,
  otherTask,
  [Obsolete]
  someOtherTask
}

rows in this table will be created as part of database migrations. Review custom migrations. First create a db migration (it will be empty), then modify it like this:

namespace LcmCrdt.Migrations
{
    /// <inheritdoc />
    public partial class TriggerRegenerateSnapshots : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql("INSERT INTO StartupTasks (Id, Task, ExecutedOn, CreatedOn) " +
                                  "VALUES (1, 'regenerate-snapshots', null, GETUTCDatetime())");
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql("DELETE FROM StartupTasks WHERE Id = 1");
        }
    }
}

[!IMPORTANT]
this code should not reference external constants. It might be tempting to make regenerate-snapshots a constant, however if that were to happen then the migration created would change over time and it should be fixed at the point of creation. Same with the SQL. You might want to define the sql somewhere and reference it from here, however migrations need to be written against the schema at the time of that migration, not the latest schema. Eg, in the example above there's 4 columns, Id, Task, ExecutedO, CreatedOn. At the time this migration is written that's all the columns, if in a future migration another column is added, this sql SHOULD NOT be changed, because that column doesn't exist when this migration is executed.

Now we've got a startup task setup, it's not been executed yet, and we need to make sure it gets executed after the migration creates it.
https://github.com/sillsdev/languageforge-lexbox/blob/8cd7ba26508c1519be7ae3f28cc657cc92d9de7a/backend/FwLite/LcmCrdt/CurrentProjectService.cs#L106-L112
We should modify that code, after migration we will query the StartupTasks table for all startup tasks where ExecutedOn is null. Then for each task we execute them one at a time setting the ExecutedOn date as we do. From there we chose what to do based on the Task column.

[!IMPORTANT]
This will have some... odd effects for newly created projects and test projects. We should consider that when building this. For example it probably doesn't make any sense to regenerate snapshots multiple times during the same startup. We might even skip it entirely when creating a new db, I'm not sure.

Start with backend/FwLite/LcmCrdt/CurrentProjectService.cs at the linked post-migration code, then compare the proposed StartupTasks table with ProjectData and review the custom EF Core migration guidance. Define how pending tasks, newly created databases, and test projects should behave before implementing; done means migration-created tasks are processed after migration and marked with ExecutedOn.