Refactoring JRA55

[simone-silvestri]

The JRA55 requires a refactor because it assumes that all the data for a variable is contained in one file.
This is true for only for repeat year forcing; in reality, multi-year forcing is contained in different files.
This requires us to restructure

1. the downloading procedure
2. the JRA55NetCDFbackend
3. the setting of the data in memory

We also need a design that allows us to possibly add different versions efficiently. I propose to generalize ECCOMetadata to a general Metadata type and structure the JRA55 data handling in the same way we do ECCO at the moment and provide a JRA55RepeatYear and a JRA55MultiYear version.

@glwagner

[glwagner]

Don't we want a different backend for repeat year vs multi year forcing?

So we don't need to refactor, we just need to create a new backend + change the name of the existing?

[glwagner]

But having a single "metadata" abstraction for all data is more ambitious. It does seem possible. Less sure about the backend. I think each data could be idiosyntratic, motivating different backends for different datatypes.

[glwagner]

If you sketch your idea here we can have a more concrete discussion