Issue title: [BUG] cu38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5split function can return one less than expected number of column vectors
 Issue body: **Describe the bug**
In a corner case where the last two(or more) consecutive split indices are equal to the rowcount of the columnvector, the number of splits returned is one less than expected as shown below.

**Steps/Code to reproduce bug**
Java unit test.
```    try(ColumnVector cv = ColumnVector.fromBoxedInts(10, 12, 13, 14)) {
      Integer[][] expectedData = {
          {10, 12, 13, 14},
          {},
          {},
          {}};

      ColumnVector[] splits = cv.split(4, 4, 4); // or (3,4,4) with expectedData ={ {10,12,13},{14},{},{}}
      try {
        assertEquals(expectedData.length, splits.length);
        for (int splitIndex = 0; splitIndex < splits.length; splitIndex++) {
          ColumnVector subVec = splits[splitIndex];
          subVec.ensureOnHost();
          assertEquals(expectedData[splitIndex].length, subVec.getRowCount());
        }
      } finally {
        for (int i = 0 ; i < splits.length ; i++) {
          if (splits[i] != null) {
            splits[i].close();
          }
        }
      }
    }
```
The assert : `assertEquals(expectedData.length, splits.length);` fails with expected = 4 and actual size = 3. The last two entries out of the three in the splits are column vectors of rowcount = 0.
If splits is called with (3,4,4) it fails in the same way. Additionally, If the splits are such that the last one is non-empty, the test will pass.

**Expected behavior**
Actual size should be 4 , with last entry being a columnvector with rowcount = 0
 Comments: 
 Comment 0: As a general comment, Java reproducers are going to be difficult for C++ devs to parse and understand (myself included). Furthermore, I don't believe any C++ devs are going to know how to run a Java repro.

Pseudo-code would be better, and a C++ reproducer would be best.

So to be sure I understand the issue, this is what is happening?
```
input {10,12,13,14}
splits {4, 4, 4}
expected { {10, 12, 13, 14}, {}, {}, {}}
actual { {10, 12, 13, 14}, {}, {} } // missing an empty partition on the end
```

In which case, this appears to be functioning in line with what the documentation says:
```
* The `i`th returned `column_view` is sliced as
 * `[0, splits[i])` if `i`=0, else `[splits[i], input.size())` if `i` is the last view and
 * `splits[i] != input.size()`, or `[splits[i-1], splits[i]]` otherwise.
```

Specifically "if `i` is the last view and `splits[i] != input.size()`" tells me that if the last split point is equal to `input.size()` then an empty slice is not generated. 

If this is not the desired behavior, we can look into updating it. 
 Comment 1: @jrhemstad , thank you for the quick update on this. I think we can work around this if the intended behavior is as documented. The (somewhat , maybe flawed) expectation was if I have `n` indices in splits no matters what the values are, they will generate n +1 split column vectors. 
 Comment 2: > @jrhemstad , thank you for the quick update on this. I think we can work around this if the intended behavior is as documented. The (somewhat , maybe flawed) expectation was if I have `n` indices in splits no matters what the values are, they will generate n +1 split column vectors.

I agree and I think that's a valid assumption. I don't think the documented behavior is necessarily ideal. It does seem a bit odd, but at least it is documented :). 
 Comment 3: @kuhushukla, @rgsl888prabhu fixed the behavior here: https://github.com/rapidsai/cudf/pull/4049
{'source': 'GithubIssues', 'repo_name_with_owner': 'rapidsai/cudf', 'issue_id': 558255114, 'repo_stars': 4402.0}