Rename Lint/AmbiguousOperatorPrecedence to Style/ExplicitOperatorPrecedence

[koic]

Follow up #10080 (comment).

This PR renames Lint/AmbiguousOperatorPrecedence cop from Style/ExplicitOperatorPrecedence.

The above link comment would make a lot of sense. And other feedback on the issue has also been commented the cop shouldn't be at a particularly high "severity" level like Lint. I think it could be considered disabled by default, but this PR moves to Style instead of Lint anyway.

I understand that it shouldn't breaking change until 2.0, but I believe this is worth the breaking change for early adopters using pending cop.

As a side note, I think this should not be enforced by source code, as it can be completed in the editor if desired.
https://twitter.com/kddnewton/status/1485712576076042241

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[bbatsov]

I understand that it shouldn't breaking change until 2.0, but I believe this is worth the breaking change for early adopters using pending cop.

I'll have to think about this, but I'm open to the suggestion in general. Plus I think we should start focusing our attention on RuboCop 2.0 soon anyways, as a lot of breaking changes have piled up in the backlog.

I also think that it's important for to start working on the "cop squads" or however we decide to name them in the end, as I think that allowing people to run some smaller more focused squads will solve much of such issues anyways.

[pirj]

What I'm most interested regarding the inheritance approach is if would offences be displayed for both the old and the new cop?

It was one of the decision-making factors for rubocop-capybara extraction to avoid duplicates, see this.

[koic]

Ah, Indeed. Redundant warnings can be confusing. I'll take a closer look later.

[pirj]

Just to avoid any confusion, redundant offences, not warnings.
This is caused by both cops being enlisted.

$ rubocop spec/cap_spec.rb
Inspecting 1 file
C

Offenses:

spec/cap_spec.rb:3:5: C: Capybara/SpecificActions: Prefer click_link over find('a').click.
    find('a[href]').click
    ^^^^^^^^^^^^^^^^^^^^^
spec/cap_spec.rb:3:5: C: RSpec/Capybara/SpecificActions: Prefer click_link over find('a').click.
    find('a[href]').click
    ^^^^^^^^^^^^^^^^^^^^^

Contrary to the inheritance approach, rename in obsoletion config tells RuboCop to fall back from the old cop to the new one, and there is no redundancy in the output. At a cost of some extra code for cops doc generation.

[koic]

Yeah. It's offense, not warning. I was using the wrong terminology 😅