Safe checkpointing

[StefanFlaumberg]

The AleRax checkpoint comprises the checkpoint directory and files within it: args.txt, fams.txt, mainCheckpoint.txt and family files storing the per-family model parameters. While the args.txt and fams.txt files are written only once, at the start of the run, the mainCheckpoint.txt and family files are overwritten multiple times during the run. This implies a practically significant chance of checkpoint corruption: an interrupted run can leave some of the latter files only partially written or not updated at all since the previous checkpoint (resulting in a mixed checkpoint).
This PR implements a simple algorithm to detect most of the practical cases of checkpoint corruption. The algorithm is based on the following ideas:

• The args.txt and fams.txt files are written always before the mainCheckpoint.txt file. So finding the latter file implies the existence of the former two.
• The AleState::serialize() function rewrites all the family files always after the mainCheckpoint.txt file. So an "incomplete" header can be put into the mainCheckpoint.txt file to signal the start of a serialize() call and later be substituted with a "complete" header to signal the end of a serialize() call. Finding a complete header implies that the mainCheckpoint.txt file and all the family files have been updated, while any other situation results in a corrupted or incomplete header.

The new AleState::checkpointExists() function is called at the start of the run. It returns whether the checkpoint directory exists. And if the directory does exist, the function checks the mainCheckpoint.txt header and aborts with a user-friendly error if the header is in any way different from the complete one.

False positive corruption detection:
Should not occur. The only possibility I see is a run interruption happening right after all family files have been updated, yet before the mainCheckpoint.txt header flip -- a time window too narrow to be practically relevant.
False negative corruption detection:
This algorithm heavily relies on the file writing order to the OS kernel buffer; hence, it does not cover checkpoint corruption cases caused by file deletion or modification or by a kernel crash. The latter can result in some files or their parts not being transferred from the OS kernel buffer to the disk. A solution to this would require using methods such as fsync(). But, unlike checkpoint corruption cases caused by a process kill, which are fully covered by the algorithm, these scenarios are quite rare.