Deprecate OnFailure()

Similar to the recent refactoring in #141, I propose to:

1. Refactor OnFailure into MapFailure and mark OnFailure as [Obsolete]. This will bring extension methods to consistency with F#'s Result at https://github.com/fsharp/fsharp/blob/master/src/fsharp/FSharp.Core/result.fs (MapFailure and not MapError because Error and IsFailure are different members in our Result and Failure is closer semantically to describing the result’s state).

2. Move the existing MapFailure methods out of Result/Result<T>/Result<T,E> to extensions that replace OnFailure ( https://github.com/vkhorikov/CSharpFunctionalExtensions/blob/master/CSharpFunctionalExtensions/Result/Result.cs#L554-L567 and similar).

@space-alien let me know if you can do that. If you are short on time, I’ll try to refactor myself this weekend.

[space-alien]

Have pushed a commit renaming MapFailure -> ConvertFailure. Work continues on the other points.

[space-alien]

I remembered your comment on #135. I had also been thinking along these lines for a while.

One option would be to refactor as follows:

Map(Func<K> onSuccess, Func<K> onFailure)
MapSuccess(Func<K> func) // i.e. the current Map behaviour (if starting with a failure, return a failure result of the new type)
MapFailure(Func<K> func) // Opposite of MapSuccess

And the same principle for Bind() and Tap():

Bind(Func<Result> onSuccess, Func<Result> onFailure)
BindSuccess(Func<Result> func)
BindFailure(Func<Result> func)

Tap(Action onSuccess, Action onFailure)
TapSuccess(Action action)
TapFailure(Action action)

Fortunately, I don’t think any of this would be a breaking change (even with the current MapFailure).

I’m still trying to decide if I have an issue with the semantics of MapFailure / MapSuccess, and their Bind/Tap equivalents. For the reader unfamiliar with the library, it may not be instantly obvious whether:

1. The func is mapped/tapped/bound IF the starting result is in the named success/failure state, or
2. The func is ALWAYS called and the returned result will be changed into the named success/failure state.

It may be pretty daft to infer (2), but any ambiguity potentially draws some of the reader’s brainpower to reach the right conclusion. And one of the benefits of this library has always been its ability to make expected behaviour obvious.

So, here’s the “blindingly-obvious” alternative…!

Map()
Tap()
Bind()

OnSuccessMap()
OnSuccessTap()
OnSuccessBind()

OnFailureMap()
OnFailureBind()
OnFailureTap()