Enable PLR1736 useless enumerate check

[Skylion007]

trafficstars

References to other Issues or PRs

Brief description of what is fixed or changed

• Adds a new ruff lint that checks for useless index accesses

Other comments

Release Notes

NO ENTRY

[sympy-bot]

:white_check_mark:

Hi, I am the SymPy bot. I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

• No release notes entry will be added for this pull request.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed
* Adds a new ruff lint that checks for useless index accesses 

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers. Formerly, `log(-x)` incorrectly gave `-log(x)`.

* physics.units
  * Corrected a semantical error in the conversion between volt and statvolt which
    reported the volt as being larger than the statvolt.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
NO ENTRY
<!-- END RELEASE NOTES -->

[oscarbenjamin]

In principle I like this rule but it seems to present an equals numbers of false positives and true positives.

[github-actions[bot]]

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1 means a speed up and greater than 1 means a slowdown. Green lines beginning with + are slowdowns (the PR is slower then master or master is slower than the previous release). Red lines beginning with - are speedups.

Significantly changed benchmark results (PR vs master)

Significantly changed benchmark results (master vs previous release)

Full benchmark results can be found as artifacts in GitHub Actions (click on checks at the top of the PR).

[haru-44]

Does a false positive refer to cases where # noqa is added? If you have concerns, I think it’s okay not to add PLR1736 to pyproject.toml.

[oscarbenjamin]

Does a false positive refer to cases where # noqa is added?

Yes. I assume that @Skylion007 checked those cases and discovered that they cannot be changed in the way that the rule suggests. That means that if the rule flags up those cases then it is reporting a false positive.

[Skylion007]

One is that it triggers in assert (which is useless but checking the operator in the assert) not really a full false positive.

The other was a really weird issue that was causing a test failure, that's the only real false positive so I left it as is.