New rule: RedundantExplicitOperatorCall

[osipxd]

This issue is continue of discussion started in #7019 (comment)

Expected Behavior of the rule

The rule should report explicit call of operator fun where it is possible to use its operator form.

Config:

RedundantExplicitOperatorCall:
    enabled: true
    # This is just an example, list of default operators is not defined yet
    operators:
      - get
      - set
      - not

Examples:

val featureFlags: Map<String, Boolean> = ...

// Noncompliant
val isMyFeatureEnabled = featureFlags.get("myFeature")
if (isMyFeatureEnabled.not()) { ... }

// Compliant
val isMyFeatureEnabled = featureFlags["myFeature"]
if (!isMyFeatureEnabled) { ... }

Exceptions to the rule

• With nullable types. Explicit call with nullable type should not be reported, as operators couldn't be called on nullable types (unless it is extension operator for nullable types):

  val featureFlags: Map<String, Boolean>? = ...
  
  featureFlags?.get("myFeature") // OK
  
  // but if we have an extension-function for nullable type
  operator fun Map<String, Boolean>?.get(key: String) = this?.get(key) ?: false
  
  featureFlags.get("myFeature") // Not OK

• Call on implicit receiver. The only possible way to use operators with implicit receiver is to use this explicitly, so maybe such cases shouldn't be reported:

  with(featureFlags) {
      if (get("myFeature1")) println("OK")
      if (this["myFeature2"]) println("Also OK")
  }

• Call chain. It may be not appreciated to use operator in a code written in functional style.

  sequenceOf(1, 2, 3)
      .filter { it % 2 == 0 }
      .plus(42) // It is an operator but it is OK to use it in call chain
      .forEach(::println)
  
  // With operator call it could be
  (sequenceOf(1, 2, 3)
      .filter { it % 2 == 0 }
      + 42)
      .forEach(::println)

• Operator-specific exceptions. Specific restrictions for operators should also be handled. For example False positive on ExplicitCollectionElementAccessMethod with spread operator #5640

Context

• It might be useful to restrict explicit usage of some operators according to project code style (see Redundant usage of Boolean.not() #7019 for example)
• There already exists the rule promoting [] over get and set - ExplicitCollectionElementAccessMethod. This rule could be implemented via the new rule