Legacy to versions

[alecandido]

At the moment, since we are transitioning, there are a lot of legacy objects:

• legacy runner
• legacy runcards
• legacy output

About the output, there is already an issue discussing the opportunity of versioning it #106
But we need to version all the input and output we use, while the runner is a different story.

So, we need to act in two different ways.
For the IO, we will declare a candidate v1 to the current format, for both inputs (runcards) and output (operator). What is now called legacy will be instead the v0, and all the code dealing with legacy IO will be moved to eko.io.v0.
The only supported actions will be loading and upgrading to v1 format. Everything else will be dropped.
If in future we will come to a v2 version, we will create a eko.io.v1 package, with loaders and upgraders to v2.

The only thing we need to decide is if versioning the input and output together (a single __data_version__, as it is at the moment), or using two separate version numbers.
Only integer versions will be supported, since any compatible change does not require a new version.

About the runner, we will simply reimplement the current one with new elements, and find a better name than legacy (this is already discussed in #138).

[felixhekhorn]

I'm inclined to say let's split input and output - since they are for the most part decoupled. The one and only interaction they have, is that the output should contain the input cards.

The runner version is the program version (so v0.11 atm) and it need to be able to act on both: suitable input and output

[alecandido]

Ok, agreed for input and output, I'll make a proposal for this after #172

There will be an extra piece, i.e. import theory from current NNPDF layout (it will update with the theory db layout itself) to current theory version. At the moment, it is mostly a copy of the v0 theory, with the only difference that v0 theory will be frozen, and it contains a few extra element (that are not present in DB entries).