All: Fixes #13782: When cleaning old revisions, ensure revisions are merged for all revision branches

[mrjo118]

Due to the distributed nature of the revision collection and cleaning in Joplin, the chain of revisions which exist for a note may not be linear. Currently, the revision cleaning logic assumes that the chain of revisions is linear, assuming only 1 revision needs to be updated to contain the merged contents of deleted revisions. This means that when the chain is not linear, part or all of the revisions for a note can become corrupted due to the 'surviving' revision for a particular branch within the revision list, not being merged before deleting its parents. For more details, see issue #13782 which this PR fixes.

This PR addresses the issue, by identifying the first child of all revisions to be deleted, and merging the diffs for children which are on or after the note history cut off date, before deleting the revisions. Additionally, I have added a new index to the db, to ensure that the new revision cleaning logic will not perform poorly with a high volume of data.

Testing

Using a backed up snapshot of my own Joplin profile, which I switched over to use file system sync, I did the following tests:

1. For an existing note with 14 days of working revisions, and 20+ days of broken revisions after that, I changed the note history cut off date to 30 days and restarted Joplin. There were no related errors in the log, and all history items older than 30 days were deleted. The revisions between 14-30 days old remained broken
2. For an existing note with 14 days of working revisions, I changed the note history cut off date to 12 days and restarted Joplin. There were no related errors in the log, all history items older than 12 days were deleted, and the final revision was correctly merged to contain the full note contents at that point. All other revisions resolve correctly to show valid contents in the UI
3. In both cases, I synced the change to the file system sync target, and then synced to a Joplin 3.5.7 client. All revision updates and deletions were correctly uploaded and downloaded onto the second client

So basically I manually tested that the existing behaviour remains unchanged. For testing the actual scenarios of multiple surviving children needing to be merged, this is covered by unit tests on the PR, as it would be difficult to set up the data in the right state in the database, unless I manipulated the data manually.

I also verified in the sqlite db directly that the migration script correctly creates the new index: