Do not lose history for a new version

@martin-ejdestig wrote
> By the way, this is something that might be worth looking into for the wrapdb webpage... ? Would make a lot of sense, I think, to be able to branch of new version branch from an older one instead of copying files and losing history.

Let's continue discussion here. I agree that solving this is a good idea. Let me try to describe the difficulty.
Each project is a git repository. Each version is a branch. Each revision is computed inside the branch. The code that I wrote just runs [BFS](https://en.wikipedia.org/wiki/Breadth-first_search) and counts number of parent nodes (including starting node) that have `upstream.wrap` file. Revision is the number of such parents. So you can see, if we just created a new branch it will have revision 1. On each subsequent commit it will increment by one. However if you clone branch it will not reset the revision. I tried introducing `[wrap version]` tag that would limit BFS from going further, it works, but I am not sure if this is clean enough approach, and when I asked people to use it few times it got ignored. Also it's relatively easy to forget to put this tag.

I have another idea we could try using. If we put version number in `upstream.wrap` itself, the we can track version change. The trick here would be to make it backward-compatible with older `upstream.wrap` files without this new field. In case we implement this, revision is number of parent nodes with `upstream.wrap` files with matching version, if version is not found then just number of parents with `upstream.wrap`.

What do you think @martin-ejdestig?

No source file or test is named. Start by locating the revision calculation and upstream.wrap parsing, then compare the two backward-compatible version-tracking proposals; done requires an agreed behavior for branch-derived revisions and older upstream.wrap files.

Written by the indexing model from the issue text.