Update the implementation of ClassOrdering to handle false negatives

[picklebento]

Resolves #3809.

With this new implementation, one noticeable changes are that the number of violations is going to be increased:
For example, in a class layout like

class MyClass {
    val a: Int
    fun b(): String
    val c: Int
    val d: Int
    val e: Int
    val f: Int
}

Previous the violation will be reported only the boundary (a <-> b, b <-> c), now it will be reported on (c, d, e, f).
If the increase in the violations is a concern, we can implement grouping logic to reduce the number of violations.

[codecov]

Codecov Report

Merging #3810 (0feafb3) into main (df4d921) will decrease coverage by 0.10%.
The diff coverage is 80.55%.

@@             Coverage Diff              @@
##               main    #3810      +/-   ##
============================================
- Coverage     83.48%   83.38%   -0.11%     
+ Complexity     3104     3102       -2     
============================================
  Files           456      456              
  Lines          8937     8943       +6     
  Branches       1751     1755       +4     
============================================
- Hits           7461     7457       -4     
- Misses          558      568      +10     
  Partials        918      918              

Impacted Files	Coverage Δ	Complexity Δ
...lab/arturbosch/detekt/rules/style/ClassOrdering.kt	81.81% <80.55%> (-10.29%)	6.00 <0.00> (-1.00)
...ain/kotlin/io/gitlab/arturbosch/detekt/api/Rule.kt	65.21% <0.00%> (-21.74%)	16.00% <0.00%> (-1.00%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df4d921...0feafb3. Read the comment docs.

[picklebento]

This is pending #3719

[BraisGabin]

Time ago I did some research regarging this rule and the number of issue that it raises. I found that we could use "longest increasing subsequence (LIS)" to reduce the number of issues. But I never implement it. I don't know even if we need to implement it. But as you talk about it I thought it could be usefull.

[schalkms]

Thanks for the fix!

[schalkms]

Is there any alternative to the null return? Then we could spare the null checks above?

[picklebento]

Kotlin documentation does not specify where we should put nested classes or objects, so the ordering for nested classes shouldn't matter from a static analysis point of view, hence it should not have any priority order - null is a reasonable choice.