PERF: RangeIndex.format performance
#35440 dropped ``RangeIndex._format_with_header``, which was functionally not needed, but needed to avoid creating an internal ndarray.

This rectifies that + gives some perf. improvements.

```python
>>> idx = pd.RangeIndex(1_000_000)
>>> %timeit idx.format()
4.6 s ± 102 ms per loop  # pandas v1.1.0
1.67 s ± 19.6 ms per loop  # master
595 ms ± 2.35 ms per loop  # this PR
```

Also, now the ``_data`` attribute isn't called, so this PR gives a perf. & memory improvement in some use cases compared to master:

```python
>>> idx = pd.RangeIndex(1_000_000)
>>> idx.format()
>>> "_data" in idx._cache
False # pandas v.1.1.0
True  # master
False  # this PR
```

looks good. this is worth a perf mention in 1.2 whatsnew. ping on green. The TravisCI issue is just a timeout issue, but In `CI / Web and docs`, I've got a problem under  `Check ipython directive errors` that I'm not able to fix:

```
Run ! grep -B1 "^<<<-------------------------------------------------------------------------$" sphinx.log
[0 rows x 1 columns]
<<<-------------------------------------------------------------------------
##[error]Process completed with exit code 1.
```

The source code for this in `.github/workflows/ci.yml` says:

```yml
    # This can be removed when the ipython directive fails when there are errors,
    # including the `tee sphinx.log` in te previous step (https://github.com/ipython/ipython/issues/11547)
    - name: Check ipython directive errors
      run: "! grep -B1 \"^<<<-------------------------------------------------------------------------$\" sphinx.log"
```

I don't understand what this check is for or why my PR fails here. @TomAugspurger, you posted that mentioned ipython issue, do you mind looking at why my PR fails on this? Updated. lgtm. I think this is ok for 1.1.2 as a perf regresion, can you move the note? ping on green. Updated & green. @topper-123 merge conflicts in whatsnew That merge brancg master has caused some strange error. anyone know how to fix it? Thanks, @simonjayhawkins, were there any git oneliners you used for this?
 > Thanks, @simonjayhawkins, were there any git oneliners you used for this?

I don't profess to know what was going on. resetting HEAD, merging master and then pulling from the branch seemed to fix except for the duplicate release note. > minor comment, if you can address and merge on green.

comment addressed Thanks @topper-123  @meeseeksdev backport 1.1.x Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
$ git checkout 1.1.x
$ git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
$ git cherry-pick -m1 b7a31ebeb873f37939838b3b788dab0e4c41b8de
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
$ git commit -am 'Backport PR #35712: PERF: RangeIndex.format performance'
```

4. Push to a named branch :

```
git push YOURFORK 1.1.x:auto-backport-of-pr-35712-on-1.1.x
```

5. Create a PR against branch 1.1.x, I would have named this PR:

> "Backport PR #35712 on branch 1.1.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                