KFold returning folds with different lengths of Train and test splits

### Describe the bug

The sizes of the train and test split change over different splits. 

For example, the size of the IRIS dataset is 150 rows. In 4-fold cross-validation, we would expect to see either 112-38 splits or 113-37 splits for all 4 folds. But actually, we are getting a mix of both. I tested this for another dataset with for 2-fold and 3-fold in which the len(data) is not divisible by 4. The same issue was there.

Would be much appreciated if someone could fix it. 

Why I need this fix is because, in my application, I have to assume that all folds are of equal sizes for a specific reason. 

Thank you!

### Steps/Code to Reproduce

```
from sklearn.model_selection import KFold,StratifiedKFold
from sklearn import datasets

def next_observation():
    iris = datasets.load_iris()
    X = iris.data[:, :2]
    y = iris.target
    n_k_splits = 4

    kf = KFold(n_splits=n_k_splits)


    for train_index, test_index in kf.split(X):
            X_train, X_test = X[train_index], X[test_index]
            y_train, y_test = y[train_index], y[test_index]
            len_tr = X_train.shape[0]
            len_ts = X_test.shape[0]
            print(("-----"))
            print(len_tr)
            print(len_ts)

next_observation()
```

### Expected Results

```
-----
112
38
-----
112
38
-----
112
38
-----
112
38
```

### Actual Results

```
-----
112
38
-----
112
38
-----
113
37
-----
113
37
```

### Versions

```shell
System:
    python: 3.10.6 (main, Oct  7 2022, 15:17:36) [Clang 12.0.0 ]
executable: /Users/nrweerad/opt/anaconda3/envs/mlp/bin/python3
   machine: macOS-12.4-arm64-arm-64bit

Python dependencies:
      sklearn: 1.1.2
          pip: 22.2.2
   setuptools: 63.4.1
        numpy: 1.23.3
        scipy: 1.9.2
       Cython: None
       pandas: 1.5.0
   matplotlib: 3.6.1
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/nrweerad/opt/anaconda3/envs/mlp/lib/python3.10/site-packages/sklearn/.dylibs/libomp.dylib
        version: None
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/nrweerad/opt/anaconda3/envs/mlp/lib/python3.10/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: armv8
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/nrweerad/opt/anaconda3/envs/mlp/lib/python3.10/site-packages/scipy/.dylibs/libopenblasp-r0.3.20.dylib
        version: 0.3.18
threading_layer: pthreads
   architecture: armv8
    num_threads: 8
```

COMMENT:
@s-banach I agree. Should n_splits necessarily be something that the len(data) is divisible by. I would expect the library to handle for cases like those. 150/4 = 37.5. So the library could make it either 38 or 37 but I would expect that to be consistent across 4 folds. Does that make sense?

Labels: Bug, Needs Triage