Follow CF conventions when determining which variables are coordinates

[TomNicholas]

This is meant to supercede #191 as a general solution to the problem of (e.g. #189).

I do think though that in order to get this test to fully pass (i.e. identify all the coordinates according to the CF conventions, then we need to use xr.decode_cf as described in #157 (comment)).

However, I'm currently having weird issues where my test is not behaving deterministically when running locally. The set of coords identified is not the same on every run!

• Closes open_virtual_dataset returns some coordinates as data variables #189
• Tests added
• Tests passing
• Full type hint coverage
• Changes are documented in docs/releases.rst
• New functions/methods are listed in api.rst
• New functionality has documentation

[TomNicholas]

I do think though that in order to get this test to fully pass (i.e. identify all the coordinates according to the CF conventions, then we need to use xr.decode_cf as described in #157 (comment)).

I've now started doing this, and the general approach seems promising (cc @sharkinsspatial).

I have 2 issues to solve before I can properly bug-hunt:

1. I had to comment out this line to avoid wrapping the ManifestArray with xarray's lazy indexing classes. I think that perhaps xarray should be changed upstream here - if I don't decode any values at all (and only alter metadata) then there is no need to wrap it in a lazy indexing class, and wrapping everything at this point seems like a mixing of different concerns inside one function. (@dcherian wondering what you think though)
2. Somehow my code is now getting to here in xarray, which tries to create a 1D pandas index, which attempts to load a ManifestArray into memory, which errors. I thought I had found all the ways that could happen so this is annoying, because (a) it might require another change to xarray upstream and (b) I do not understand why this is happening with this PR but not without this PR.