Use new predict function for R.

[trivialfis]

This is an early PR so I can get some suggestions from R experts. The primary change in R interface is the use of iterationrange and deprecation of ntreelimit.

TODOs:

• Remove the use of ntreelimit in internal code base.
• Document its deprecation.
• Figure out how to utilize the shape returned by the new predict function.
• Add new tests for both iterationrange and strict_shape.
• Handle 1-based indexing for best_iteration.

[codecov-commenter]

Codecov Report

Merging #6819 (48d5105) into master (7beb2f7) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #6819      +/-   ##
==========================================
- Coverage   81.72%   81.71%   -0.01%     
==========================================
  Files          13       13              
  Lines        3917     3916       -1     
==========================================
- Hits         3201     3200       -1     
  Misses        716      716              

Impacted Files	Coverage Δ
python-package/xgboost/core.py	82.83% <100.00%> (-0.02%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7beb2f7...48d5105. Read the comment docs.

[hcho3]

Should we use 0-based index here?

@jameslamb What's the convention for R packages that wrap native code? Do users expect to use 1-based indexing?

[hcho3]

Also, please add a note that iteration_range=(0,0) indicates the use of all trees.

[jameslamb]

In general, I'm in favor of parameters like this being 1-based and having the documentation clearly indicate that. I think that's more friendly for R users.

But, to be fair, in {lightgbm} we have not been very consistent about this. Keyword arguments in the package's interface expect 1-based values, but {lightgbm} won't look inside parameters passed through a list params and subtract 1 from any parameters that are indices.

So I think that there is not really a "right" answer to this, and that it's more important to:

1. be consistent (as much as possible)
2. over-communicate in the documentation (always say whether it is 1-based or 0-based)

[trivialfis]

I will try to use 1 based index.

[trivialfis]

Changed to use 1-based index. Thanks for the suggestions!

[Kodiologist]

I recently found a segfault in version 1.4.1.1 of the R package when providing ntreelimit greater than the number of trees in the model, but I'm guessing the bug no longer exists in XGBoost master, due to this PR.

[trivialfis]

@Kodiologist Did you test it? I think I have error tests in Python with model slicing, but not 100 percent sure about R error handling.

[Kodiologist]

No, not with anything newer than 1.4.1.1.