[MRG+1] Add decision_function for OneVsOneClassifier.

Adding `decision_function` support for the `OneVsOneClassifier`.

This is based off of #1548 and addresses #1523.

- [x] Implement the `decision_function` for `OneVsOneClassifier` 

decision_function returns `votes + scores * (0.4 / max(|scores.max(axis=None)|, |scores.min(axis=None)|))`

As a corner case, when both max and min are same, it simply returns `votes`.

- [x] Add tests for ovo decision function
* Tests `decision_function(X).argmax(axis=1) == predict(X)`
* Tests `decision_function(X).shape == (n_samples, n_classes)`
* Tests `np.round(decision_function(X)) == separately_computed_votes`
* Tests `computed_scores = (decision_function(X) - np.round(decision_function(X)) ) * upscale_factor_derived_from_computed_scores `

- [x] Incorporate the `decision_function` output in `test_ovo_ties`
`ovo_ties` test requires `votes` to assert tie and `scores` to assert if the prediction breaks ties using aggregated decision scores. Both `votes` and `scores` ( individual ) were separately computed till now. These are modified to use `decision_function`
* `votes = round(decision_values)`
* `scaled_aggregated_scores = decision_values - votes`

@arjoly, @amueller, @mblondel  Pl. review when you find time!
Sorry for the late reply... Was in the middle of my end semester exams...

@mblondel I am sorry... I am not quite sure I follow you... but if you were asking if this scaling could possibly affect votes for some other example... 

The class votes for a sample `[x, y, z]` can either result in : 

1. Tie ( `x = y = z` ) - In which case the added scaled scores must distinguish them, `[ x + s1, x + s2, x + s3 ]`  i.e  `x + s1  !=   x + s2   !=   x + s3`

2. Not a tie - Where the addition of scores actually serve no purpose and should therefore should neither do any harm.

The caveats that impose the range of `si` :

1. In case 1, if `x > y` and `x = z`. The addition of scores to break the tie must not make `x + s1` or `z + s3` less than `y + s2`.

2. In case 2, if `x > y > z` This inequality should not be affected by the addition of the scores for all values of `x`, `y`, `z`... ( `x + s1 !<= y + s2 !<= z + s3` )

This can only happen if the range of s lies within `[0, 1)`  or `[-0.5, 0.5)` preferably ( `(0, 1)` or `(-0.5, 0.5)` ).

Scaling to the `(-0.5, 0.5)` is not possible perhaps we could do `[ -4.999999, 4.999999 ]`... So I used `[-4, 4]` as it is much simpler to scale to.

This explanation is based on my understanding so it might be unnecessarily detailed than is necessary. Kindly excuse if this is not what you had asked me... :)

@larsmans @MechCoder The motivation for not returning just the `votes` was to make sure that `argmax(decision_function(X)) == predict(X)`.

[ Predict earlier calculated the `scores` and `votes` separately and chose to use `scores` when `votes` got into a tie, on a per sample basis. This behaviour is generalized in the `scaled_scores + votes` approach ]

The `decision_function` of linear models like `svm` seems to return the decision values of shape `n_samples x ( n_estimators )` which seems to be non conforming with the rest of our API based on [this](https://github.com/scikit-learn/scikit-learn/pull/3891#discussion_r21045980) discussion.

But please let me know if simply returning the `votes` is preferable.