Refactor FiniteDiff into separate differencing, derivative, and advection classes

[spencerahill]

Effectively none of the FiniteDiff methods use any of its data -- hence them all being static or class methods. So those methods should be written in a general form in their own module, and then the FiniteDiff class re-implements them using its data.

[spencerahill]

That there should be a refactor is right, but the original idea behind this issue was flawed. These should remain implemented as classes, but FiniteDiff should be refactored into at least three classes:

• FiniteDiff: finite differencing only (plus helper methods), no derivatives
• FiniteDeriv: finite differencing derivative methods (plus helper methods), no advection. Inherits from FiniteDiff?
• Upwind: upwind advection methods only (plus helper methods). Inherits from FiniteDeriv? Potentially a parent Advec class that Upwind and any subsequent advection classes inherit from?
• (Eventually) Sphere: method for converting between cartesian and spherical geometries. Potentially a parent Geom class that Sphere and any subsequent geometry classes (cartesian; doubly-periodic cartesian) inherit from.

Re: creating modules also, that is a low priority.

[spencerahill]

The diff, deriv, and advec modules have been implemented, each with classes for the various methods described in the title. The geometery/coordinate parts are a separate issue and are currently being implemented.