add .success / .failure methods that cause sideeffects only

[tamamachi]

It will be handy if we could just add event handlers without changing values or types of Tasks
(now SwiftTask requires .success / .failure closures to return a new value or Task).
In particular, it's painful to use .failure when you just want to add an event handler and don't want to recover from failures, because it still requires successful return value.

This PR adds .success / .failure methods which have closures of returning type Void for their arguments.
You pass a closure returns nothing (or Void), and you get a new Task nearly identical to previous one but it keeps the closure as an event handler.

This change disables handling Tasks with Void as the Value type (eg. Task<Progress, Void, Error>), but no one might want to use such creepy Tasks 😉

[inamiy]

Hi, thank you for pull request 😄

It looks good to me at first glance, but unfortunately, your implementation will break existing API because of ambiguous use of functions. Please cherry-pick d9f2191 (submodule-fix) and test if same issue will happen on your Mac.

(Note: CircleCI seems to pass XCTest, but actually I didn’t configure this async test on purpose...)

To improve this, I’m thinking of renaming it as func on(success:failure:).
This method name is used in ReactiveCocoa and also has similarity with Scala’s future.onSuccess()/onFailure().

Also, I’m thinking of returning same task rather than creating new synchronous task.
Though this sounds not functional-programming-like, it improves overall performance by skipping instantiation.

[inamiy]

I improved your idea in #51. Will you please check this?

[tamamachi]

Thank you for your review! #51 will be much greater.