FKTables should come with a version

Created by: Zaharid

There have been several attempts to add some sort of version control to fktables, which unfortunately never went very far. So far the generic issue is #224, but that is a bit of a long shot at the moment. We want something sooner.

The proposal would be to burn some fktable metadata, which can be retrieve like

In [1]: from validphys.loader import Loader                                                                           

In [2]: l = Loader()                                                                                                  

In [3]: from validphys.fkparser import load_fktable                                                                   

In [4]: tb = load_fktable(l.check_dataset('ATLASTTBARTOT', theoryid=53).fkspecs[0])                                   

In [5]: tb.metadata['VersionInfo']                                                                                    
Out[5]: 
{'APFEL': '3.0.4',
 'APPLrepo': '49083b85986bc2bd0fc9eae9550388a2028c75f4',
 'GenTime': 'Tue Apr 16 23:16:30 2019',
 'libnnpdf': '1.2.0b5'}

(although we probably want a simple integer version field which is increased whenever there are bugfixes) which for simplicity we require to be the same for all fktables in the dataset, so it has an unique fkversion attribute. We could maintain different compound files for each version in a way that it is possible to get the old fktables.

The fkversion of the dataset would be added to the lockfiles, and we would have actions that do something similar to https://vp.nnpdf.science/_J7MbOOeRhynt1Hoe2mQqg==/#dataset-differences-and-cuts to show differences in fktable versions.

When loading, if fktable versions are specified, they would be checked against the files (I guess compound files). If no version is given, one would get the latest version, ensured you do the likely correct thing by default, but keeping a record on the actual version in lockfile.

I suppose we would implement all this for #515. Note the similar discussion for commondata files #494 (closed).