Refactor info to allow datetime inputs from xarray.Dataset and pandas.DataFrame tables

[weiji14]

Description of proposed changes

In order to support datetime inputs into pygmt.info, this PR changes the backend mechanism from using lib.virtualfile_from_matrix() (which only supports single non-datetime dtypes) to using lib.virtualfile_from_vectors() (which supports datetime inputs as of #464).

Note: While datetime inputs can be passed into info now, the resulting outputs (UNIX timestamp instead of ISO datetime) might not make sense due to the issue at GenericMappingTools/gmt#4241.

Coincidentally, this refactor also enables the following:

• Properly handle pandas.DataFrame table inputs that may have mixed dtypes (e.g. int32/float32 on different columns, see also Add a test to check passing arrays of mixed dtypes to GMT #547).
• Passing in xarray.Dataset inputs! Note: Only for xarray.Datasets made up of 1D xarray.DataArrayss (e.g. what you might get from using xarray.Dataset.from_dataframe).

Addresses #597, will be fixed once GenericMappingTools/gmt#4241 is resolved.

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

[weiji14]

Note that this test currently fails, giving what looks like a UNIX timestamp rather than an ISO datetime output:

E       AssertionError: assert '<vector memo...1578182400>\n' == '<vector memo...5T00:00:00>\n'
E         - <vector memory>: N = 5 <10/15> <2020-01-01T00:00:00/2020-01-05T00:00:00>
E         + <vector memory>: N = 5 <10/15> <1577836800/1578182400>

Will need to investigate, but any idea why this is happening? Or is this expected behaviour?

[seisman]

GMT_Put_Vector started to accept datetime strings in PR GenericMappingTools/gmt#3396. In this implementation, all datetime strings are converted to double internally.

Looks like a GMT API bug to me.

[weiji14]

So the inputs are read correctly here, we can pass in datetime types using the GMT_DATETIME enum. The output is also the correct UNIX timestamp range, but I doubt it's something users would expect.

I suppose we can xfail this for 6.1.1, but would prefer to have this reported and/or fixed in GMT master first (i.e. for 6.2.0) Edit: issue opened at GenericMappingTools/gmt#4241. A workaround might be to use np.datetime64(1577836800, 's') to get numpy.datetime64('2020-01-01T00:00:00'), but this isn't a nice solution.

[seisman]

I suppose we can xfail this for 6.1.1,

Yes to me.