Fix early stopping in the Python package

[hcho3]

• Consistently choose the last validation set + last metric combination as the early stopping criteria.
• The order between metrics should be preserved, so that the user will have certainty of which metric will be used for early stopping.
• Clarify the semantics of early stopping in the Python API doc. Preview: https://hcho3-xgboost.readthedocs.io/en/fix_early_stopping_python/python/python_api.html#xgboost.train

Closes #4630
Closes #4421

[hcho3]

In the future, I may want to overhaul how the evaluation metrics are passed from C++ to Python/R/Java. Currently, the C++ function XGBoosterEvalOneIter() is returning a string consisting of metric names and values all combined. This means that Python/R/Java bindings have to parse the returned string. It may be better to have the C++ function return a structured object instead (something like a key-value store).

[hcho3]

@sriramch @rongou

[sriramch]

Currently, the C++ function XGBoosterEvalOneIter() is returning a string consisting of metric names and values all combined. This means that Python/R/Java bindings have to parse the returned string. It may be better to have the C++ function return a structured object instead (something like a key-value store).

@hcho3 are there plans to use protobuf or similar serialized data formats for things such as this? this may also have a nice side effect of supporting compatibility when the return data evolves, as opposed to a binary structs.

[trivialfis]

@sriramch There is a RFC of using JSON for everything. But currently I'm not sure about its priority.