Add Muller's method

[fgittins]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

This implements the algorithm discussed in #403.

An older pull request was opened in the since deprecated SimpleNonlinearSolve.jl package (see SciML/SimpleNonlinearSolve.jl#139). This implementation uses the suggestions made in that pull request and implements the Muller algorithm as an IntervalNonlinearProblem under the BracketingNonlinearSolve.jl sub-library.

Moving forward, I think we need to

• Re-work the simple tests I have added to be more consistent with the other algorithms (see muller_tests.jl).
• Include some functionality to allow the user to instead specify the middle guess. To be consistent with the other algorithms, currently the middle guess is taken as a midpoint of the two (left and right) specified guesses.

[ChrisRackauckas]

Add the algorithm into the other test sets: https://github.com/SciML/NonlinearSolve.jl/blob/master/lib/BracketingNonlinearSolve/test/rootfind_tests.jl#L10-L79

[fgittins]

Add the algorithm into the other test sets: https://github.com/SciML/NonlinearSolve.jl/blob/master/lib/BracketingNonlinearSolve/test/rootfind_tests.jl#L10-L79

Just implemented this now.

To do this, I needed to provide the solution the fields left and right. I made the choice to return the final point in both. Another option would be to return one of the two other points that the algorithm calculates.

[ChrisRackauckas]

This algorithm isn't bounds refinement, so that makes sense.

[fgittins]

I've implemented a feature that allows the user to specify the middle guess, along with some unit tests.

The way this is implemented is at the algorithm level, where there is now an optional middle keyword argument,

Muller(; middle = nothing)