Splitting ColocatedData with the goal of accounting for vertical profiles

[lewisblake]

This is a (mostly failed) attempt at splitting up ColocatedData for the eventual inclusion of 3D spatial fields and 4D spatio-temporal fields. Hence this is not a real draft PR, but mostly keeping this here for posterity until we decide how to proceed.

The goal was to make ColocatedData a parent class and then create derived classes ColocatedData2D and ColocatedData3D. Trying to put everything agnostic to the number of spatial dimensions into the parent class ColocatedData left very little in ColcatedData2D (about 350 lines of code).

Daniel and I realized that this is not a trivial task, and discussed what we would want out of "an ideal colocated data class". We for the time being agreed that it would be ideal to only have colocation done on the tuple (lon, lat, alt, time), instead "dimensions" such as the station name. This is geared towards accounting for the vertical profile data and is basically the point-cloud idea Jan has brought up before. We want to discuss this in our next meeting, because creating and entirely new colocated data class is a huge overhaul.

[lewisblake]

Note to self: PointCloudData class

Natural question: Why doesn't UngriddedData work for this case? A: Fundamentally UngriddedData returns instances of StationData to be in a useable format, so that the colocation can work with just the station name. When dealing with e.g., satellite data, the notion of a StationData no longer makes sense. Instead we are going to have orbit files, which either need to be pre-processed into a single file every 24 hours or have the class be able to build the iris cube on the fly from individual orbit files.

Fundamental object either iris.cube.Cube or possibly xarray.Dataset, more likely the former.