Fix pyreverse type hinting for class methods

[teobouvard]

This commit fixes the alignment of arguments and their type annotations
in pyreverse printer output.

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
  Not a feature, is it an important bug fix ?
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🐛 Bug fix

Description

Until now, the following class

class Example:
    def method(self, arg: int):
        pass
    
    @classmethod
    def class_method(cls, arg: int):
        pass
    
    @staticmethod
    def static_method(arg: int):
        pass

would generate the following PlantUML diagram when running pyreverse -o puml example.py

@startuml example
class Example {
  class_method(cls: int, arg)
  method(arg: int)
  static_method(arg)
}
@enduml

This output displays wrong type hints because the alignment of arguments and their type annotations is based on the first argument having name self. This is not the case for class methods, where the first argument is usually cls and static methods where the first argument is not related to the class.

This commit fixes the issue by performing the alignment using the method type rather than the parameters names. This generates the correct class diagram shown below.

@startuml example
class Example {
  class_method(arg: int)
  method(arg: int)
  static_method(arg: int)
}
@enduml

[coveralls]

Pull Request Test Coverage Report for Build 1953999813

• 5 of 5 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.007%) to 94.011%

---

Totals
Change from base Build 1952197418:	0.007%
Covered Lines:	14944
Relevant Lines:	15896

---

💛 - Coveralls

[teobouvard]

I'm going to try to cover the else branch to prevent a decrease of code coverage

[DanielNoord]

@Pierre-Sassoulas, did you change the coveralls setting to disallow decreasing coverage PRs? The CI seems to have passed on that commit that did not have full coverage.

@teobouvard Thanks for the contribution! I have requested a review from @DudeNr33 as they are the pyreverse expert I believe.

[Pierre-Sassoulas]

did you change the coveralls setting to disallow decreasing coverage PRs?

No, I think it can be problematic, for example in #5874 (comment) we removed code and the coverage decreased. I don't want to (have to) deal with this kind of false positive. I think the easier thing to do would be to check the coverage before approving.

[DudeNr33]

Nice cleanup and lowering the indentation level!

[DudeNr33]

Nice catch, thank you for the fix. Looks good to me, well tested with both relevant cases added to the example test data. 👍

Only thing I noticed: this PR was set to milestone 2.14.0, while the changelog has the change listed for 2.13.0.

[Pierre-Sassoulas]

Thank you for the quick review @DudeNr33 👍 Let's put it in 2.13 then !