Make robust

[fabern]

This PR makes map2tidy more robust (solves #2):

• consistent return value (nested data.frame if time present, non-nested otherwise) regardless of input options (e.g. do_chunks, ncores)
• handling of multiple calendars (e.g. julian, 365_day (a.k.a noleap), 366_day, 360_day)
• Increase verbosity
• Streamline code (apply DRY principle)
• Store RDS with lon-value in filename (instead of lon-iterator)

Handling of calendars was achieved by returning strings in the 'datetime' column of the tidy data.frames. Parsing of these strings, if necessary, must be done afterwards by the user. Then days such as "2021-02-30" (valid in a 360_day-calendar), can be handled accordingly.

[stineb]

Wonderful. Thanks. Some checks are not passing. That's why I haven't merged just yet.

[fabern]

Yes, this is still in the draft state.
I'm finishing the last TODO item to rename the RDS files now.

The checks are failing because I require the development version of tidync. The workaround for the older is already in place. It just has to be activated as default.

[fabern]

@stineb Should we increase version number to 2.0.0?
API changes are incompatible and require a MAJOR increment.

[stineb]

Yes, calling this v2.0 makes sens. However, we haven't tagged anything yet and haven't created releases. Let me know before you create a release so that I can sync it to my Zenodo.

[stineb]

Is there a reason for changing from varnam to varnames? I used varnam because I call it that way in some other functions that are now in {rgeco}.

[fabern]

The reason I changed varnam to varnames was to make more evident that it can be a vector of strings.
Since I was changing anyway the API I felt this clarifies the use cases.
Should I roll back to using varnam?