Design and create project update mechanism

[karliss]

Practice shows that delaying implementation of update procedure until the moment when it's actually required result in suboptimal solution or it being completely ignored and breaking changes.

Things to consider:

• Update procedure should be able to handle more than one version. Until r2db is done the update procedure should contain at least 2 update steps as example.
  • Update code structure: inline with deserializer or separately before running deserializer.
  • Version bump and update implementation procedure: once per release, after each modification, somewhere between.

[thestr4ng3r]

This is my initial idea:

• Version is just an integer and bumped on every change in r2 that changes the project format in any way, not per release. It is defined here: https://github.com/thestr4ng3r/r2db/blob/9c33973adc62f0b77c28143149d15970aff895de/src/project.c#L12
• For every version change, a migration function is added that takes the sdb from version n-1 to n (inline, this has the advantage that it does not need to depend on r2 structures that might change). These would be applied sequentially until the current version is reached here (not yet implemented): https://github.com/thestr4ng3r/r2db/blob/9c33973adc62f0b77c28143149d15970aff895de/src/project.c#L49

Testing this is extremely important. Ideally, we should keep saved projects for different versions and add tests that r2 still loads all the information from them. So it should be more or less impossible to break compatibility by accident. The question here is how much exactly to test. If we keep a full project for each version and test every possible kind of data on it, we will have a lot of redundant testing.