Image database model documentation and code contradict each other on what a version is

[ValentijnvdBeek]

Summary

Our database defines what an image should look like, this includes how the version system works. The code inherited from last year however contradicts itself three times on what exactly a version is supposed to be. There were three definitions given: one in the code, one in the documentation and one as an in-line comment.

In the model it uses the [time.Time](https://pkg.go.dev/time#Time) type which is a value which looks like: "yyyy-mm-dd hh:mm:ss + nsec nanoseconds". A comment put right above it said that the value is supposed to be a UNIX time stamp of some sort. In the comments at the bottom it gives the following specification on how the disk ought to look like:

/disks
	/abc
		/1.img
		/2.img
		/3.img
		/4.img
	/cdf
		/1.img
		/2.img

At the moment I assumed that the usage of the Time type is a bug which wasn't discovered yet since the version feature was not yet implemented. Hence it was switched to a int64 value which stores the UNIX time stamp as specified in the code documentation. This may however not be the best solution.

Proposed fix

Personally, I think that the UNIX time stamp format is a bit superfluous. Since the disk names are already unique IDs and the version IDs would be always increasing, the chance on name conflicts is already impossible. It potentially confusing since it makes it harder to tell which version you are dealing with or want to select. Finally, UNIX timestamps don't solve the actual issue of unique names for each image. It is possible, if unlikely, that two images are written at the exact same time.

[ValentijnvdBeek]

Done in #43 where images are versioned sequentially or have a checksum