Fix overflow for Midpoint

[LukeMathWalker]

This provides a fix for #27, I have also included a test to reproduce the issue so that we can be aware of regressions.
Unfortunately, it's a breaking change PR because I have had to add Sub to the trait bound. Should we just use NumOps for all Interpolate implementations @jturner314?

[jturner314]

The PR looks good to me.

Should we just use NumOps for all Interpolate implementations @jturner314?

I don't think so, because e.g. Lower and Higher don't need to do any arithmetic. The reason why we have an Interpolate trait anyway is to minimize the trait bounds on the element types. (Otherwise, if we require the same trait bounds for all element types, we might as well just replace all the the types that implement Interpolate with a single enum.)

[LukeMathWalker]

Sorry, my wording was not precise. I meant using NumOps as trait bounds for all those requiring mathematical operations (mainly Linear and Midpoint). It's very easy to be minimal (Add but not Sub) but this leads to needless breaking changes in the API (such as this one) which could probably be avoided by saying "you can use this if we can do arithmetics with your type".

[jturner314]

Oh, I understand now. Sure, requiring NumOps for Linear and Midpoint seems reasonable and would help avoid breaking changes in the future.

By the way, thanks for taking care of this issue!

[LukeMathWalker]

By the way, thanks for taking care of this issue!

I am actually quite thrilled that this crate has its first legit user (and bug report, as it often goes) 🚀

[LukeMathWalker]

I have added the NumOps trait constraint - I'll squash and merge.