Add callbacks to outcomes

[tfausak]

Fixes #139.

Interaction
  .run(inputs)
  .when_invalid do |outcome|
    # ...
  end
  .when_valid do |result|
    # ...
  end

[AaronLasseigne]

1. What do we get by doing this?
2. Why the when_ prefix?
3. Is there a situation where you succeed but still want the outcome? You can always get to result form the outcome but not the other way around. Should they both be getting outcome?
4. Should we force users to provide both cases if they go this route?

[tfausak]

1. An alternative way to deal with interaction outcomes. It's arguably easier and more explicit.
2. I thought it read better. I'm willing to remove it, though.
3. The only situation I can think of off the top of my head is needing the valid inputs after running the interaction. But I didn't want to yield the outcome to the valid block because then the first line of every block would be result = outcome.result.
4. That's interesting. I hadn't considered it. Is it really necessary since there are only two cases to consider? I guess it's not too much overhead to do .when_invalid { |_| }.

[tfausak]

After thinking about it some more, I'm confident that we shouldn't yield outcome to the valid block. That would be like returning outcome from run!, which we decided against in #26.

[tfausak]

I'm assuming you got the idea to require both cases from David Copeland's RubyConf talk. To make our code work like his code, I think we'd have to change it a little.

Interaction.run!(inputs) do |outcome|
  outcome.invalid do |errors|
    # Do something with outcome and errors.
  end.valid do |result|
    # Do something with outcome and result.
  end
end

If we didn't do something like this, there would be no way to know if all of the cases had been provided.