Proposal: Add "benefits" section to all rule docs

[ST-DDT]

Currently, all rule documentation is basically structured like this:

• What does it do
• Incorrect examples
• Correct examples

I would like to propose adding a "benefits"/reason section/information to/after "What does it do"

• What does it do
• Benefit/Reason
• Incorrect examples
• Correct examples

Example reasons:

• "This rule helps with code consistency"
• "Avoids issues with legacy nodes version"
• "Prevents incorrect usage of assertion methods"

Adding this information helps users determine whether they want to enable/disable a rule for themselves and also provides a basic rationale why it was/may have been added to the recommended/any other preset.

This is mostly relevant to rules, that ban certain usages without explicitly providing an alternative such as
no-conditional-tests.

Using that rule as an example, it explains that it marks conditional tests, but not why it marks them/what the risk of conditional tests are.

Sonar (and other lint rules) contain a reasoning for why the rule is there: e.g. https://rules.sonarsource.com/java/RSPEC-888/

Rule: Equality operators should not be used in "for" loop termination conditions
Reason: Testing for loop termination using an equality operator (== and !=) is dangerous, because it could set up an infinite loop. Using a broader relational operator instead casts a wider net, and makes it harder (but not impossible) to accidentally write an infinite loop.

Besides adding it to all existing rules, it should probably be added to the guide for new rules.
I'm willing to create a PR, though I may need help with guessing the (correct) reason for some of the rules.

[veritem]

@ST-DDT The "reason" section is not there due to my limited time when I was starting this project. I'll be happy to review a PR that adds it.