GRIB support for saving time increment for time aggregated data (PDT4.8)

This PR enhances the existing code for saving data in PDT 4.8. As well as refactoring the code it adds support for parsing and saving the cell_methods on cubes to determine the interval (e.g hourly or daily) of the data that has been summed/averaged/...
I thought about this and decided against it. The increment is good to have, but the most important part is the type of aggregation. I'd rather not blow up because of a peculiar intervals string. I could put in a warning, but it's difficult to give a clear steer to the user what to do to fix the problem (it might just be that the units are days, which is perfectly valid, just not supported by the current code).