Additional rules for analyzing test code

[adangel]

Is your feature request related to a problem? Please describe.
This is a feature request originating from the User Survey.
Right now the feature request is very vague and before implementing it, it should be properly defined. Once that is done, the title of this issue should be updated to correctly describe the content.

Describe the solution you'd like
Possible rules can be taken from https://www.tusharma.in/smells/TEST.html

Here are some examples:

• Assertion Roulette: This is actually JUnitAssertionsShouldIncludeMessage
• Dead Fields: This is partially UnusedPrivateField.
  For test classes it is suggested to also consider inherited fields. That would require more knowledge about the analyzed project
  (e.g. knowing all usages in all classes).
• Eager Test: This is maybe JUnitTestContainsTooManyAsserts.
• For Testers Only: ? - similar to dead fields, but for methods: Would need a usage knowledge over all classes in the project. If the method
  is public, that we can't be sure, that no other code is using it, that we don't know about while analyzing.
• General Fixture: ? - maybe a (abstract) base test class, that is used by too many tests?
• many more...

These rules should be marked or grouped somehow to make it obvious, that these rules are intended for test code.
Maybe a curated ruleset could be provided (similar to quickstart).

Describe alternatives you've considered
TODO

Additional context
TODO