Update sol save/load; add test

[jeffjennings]

I ran into an issue saving/loading a sol object from a debris fit -- pickle was struggling to interpret sol._vis_map._scale_height as a function:

saving: AttributeError: Can't pickle local object '<some function for H(R)>'
loading: OSError: Failed to interpret file '<some path>_frank_sol.obj' as a pickle

Replacing pickle with dill resolves this. PR changes:

• io.py: Updates pickle calls to dill
• tests.py: Adds test for save/load of a sol from a standard and debris fit

[rbooth200]

So _scale_height is a function (or class object), but it's probably ok to remove it from the visibility mapping object. I'd just store the result of scale_height(self.r) as _scale_height instead of the function itself.

That said, would this issue still arise if you used a class / function to specify the scale-height in fit.py instead of eval-ing a user argument? The reason I ask this is because eval is a security vulnerability so we should not use it with general user input.

[jeffjennings]

Ah ok I see. I was using eval in order to parse a scale-height function from the parameter file (at one point you suggested scale-height should be a function in the .json). Is it just enough for practical purposes to make scale_height in the .json a float that goes into an H(R) function in fit.py as scale_height * R?

I've reverted dill to pickle and changed self._scale_height to scale_height(self.r) in VisibilityMapping.

[rbooth200]

I'd probably choosing something slightly more flexible, e.g. a power law with a cut off. Maybe:H(r) = h0 r**a exp (-(r/r0)**b) but I don't really mind. We provide complete flexibility though the library version anyway.

[jeffjennings]

Ok I implemented the power law in #195. This PR has very minor changes then, ready for review.

[rbooth200]

Can you add back the save/load test? It will catch problems with pickle should they arise again.

[jeffjennings]

Sure, done in 3e79f22