made first order actually first order and added fourth order

[pavelkomarov]

Addressing #104. The resulting first_order is biased to one side, resulting in drift when it's iterated:

This is likely why you attempted some forward-backward averaging, @florisvb.

Honestly, is it worth keeping around first_order? My guess is it's not in wide usage, because the higher order methods are equally usable and right there for the taking. Iterating first_order might be a thing people do, but in that case they're actually iterating second_order, so we should update the code to reflect that and feed them a warning if they try to call first_order.

[pavelkomarov]

The first order bounds only get a touch worse when we make first_order truly first order.

[pavelkomarov]

The "iterated_first_order" bounds get worse all over the place, because the horizontal bias introduced by a non symmetric first-order method causes drift over the iterations.

[pavelkomarov]

The first_order method has been a workhorse across the repo, so I'm replacing it with second_order internally.

[pavelkomarov]

Let's merge this one after #125. I think I'm going to want to make a couple follow-on commits to it. I need to:

• move num_iterations to second_order and fourth_order
• go through the code looking for places iterated first order is called and have them call iterated second order instead
• address _x_hat_using_finite_difference investigation #87
• update the usage notebooks to include fourth_order