Refactor Interpolation

[mpu-creare]

• Right now interpolation is a large if-else statement as part of DataSource.
• The logic for determining the data that's included in the get_data request is fully determined by the Coordinates.intersect method -- this should not be the case.
  • Nearest-neighbor interpolation needs considerably fewer points that bi=linear interpolation
  • How are out-of-extents cases handles
  • point vs. segment coordinates now matter a lot more
• What do to about different CRS?
• Interpolation should be its own module
  • Interpolants should be easy to add
  • There should be an order of priority for interpolators
  • Each interpolator should know what coordinates it can interpolate to/from
  • Each interpolator should know how to select appropriate coordinates from the datasource
  • Multiple interpolators may be required for each request:
    • Time could use NN interpolation
    • lat/lon could use bilinear with a specified CRS/Projection
  • The order of these multiple interpolators matters from an optimization perpsective
    • Consider the size of the dataset before/after interpolation
    • Consider the cost of the interpolation operation

[mlshapiro]

Rough overview of plan:

• define Interpolator abstract class architecture and API
• define DataSource integration and configuration of Interpolator
• move current interpolation methods to Interpolator classes and achieve current functionality with old methods (using new API)
• implement new Interpolator features
• refactor old methods to support new interpolator features
• add new interpolators

[mpu-creare]

• Note, this will break the SMAP node. Interpolation_tolerance will be the problem. See MPU when this is ready.

[mlshapiro]

@mpu-creare ready to merge - I am going to close this issue and restart a new issue for 0.2.1 to fix the open issues above.

See 0caf984 for interpolation_tolerance refactor in SMAP. You can show me how to test this today