[R] Use type argument to control prediction types

[david-cortes]

ref #7906

In R packages for statistical modeling, the predict functions for model objects tend to allow switching between different prediction types such as probabilities or classes through a parameter type (for example, base R's predict.glm does it like that).

xgboost offers several mutually exclusive parameters to control prediction types (outputmargin, precontrib, predinteraction, predleaf). This PR merges them all into a single type parameter in line with base R and other popular packages, adding an option to predict classes for classification objectives.

Note however that objective multi:softmax is problematic in this scenario, since it doesn't allow switching between probabilities and classes on the fly, so an exception about it is mentioned in the docs.

Right now the code logic is to check the objective and determine if and how it should determine the predicted class from the outputs, but:

• I wasn't able to find any C-level function to extract the booster's objective, and am not sure that the way is done in this PR is ideal.
• It currently lists a set of objectives which allow class prediction from the original output, but I think a better approach would be to check if the objective starts with binary or multi - problem with such approach right now is that multi:softmax doesn't output probabilities.

Disclaimer: this is likely to cause several breakages in R packages that depend on xgboost.

[trivialfis]

Thank you for the work on aligning XGBoost with the R ecosystem. I will take a deeper look later to see if it's possible to keep the compatibility with some deprecation warnings. Otherwise we will have to run a reverse dependency check and talk to other projects before cran submission for the next release.

[trivialfis]

@hetong007 Would you great if you can help review the changes.

[hetong007]

In terms of the potential breaks, may I suggest that (at least in the next release) we keep both the new argument type and the old set of arguments? In this case, users can work with predict in either way. Just when users predict with the old arguments, predict throws out a deprecation warning.

Moreover, by setting a higher priority to type we resolve the case where the new and the old are conflicting.

[david-cortes]

Added deprecation warnings and acceptance of the old argument types.

[hetong007]

My only concern with warning is that it might break CRAN checks of reverse dependencies. We need to talk to their maintainers before pushing this change to CRAN.

[david-cortes]

It most definitly will. Good thing is, next version is going to be a 2.0, which signals a major release and thus potentially breaking changes.

[hetong007]

In concept for general development this is true, while for CRAN it still regardlessly breaks reverse dependencies and got Ripleyed.

[mayer79]

Changing the interface of predict() will definitively cause chaos, not only on CRAN.

[david-cortes]

Renamed the types to be more in line with base R.