Add ExplicitThis recipe to make 'this.' prefix explicit.

[motlin]

What's changed?

Added a new ExplicitThis recipe that automatically adds the explicit this. prefix to instance field accesses and method invocations.

What's your motivation?

This recipe improves code clarity by making it immediately obvious when a field or method belongs to the current instance versus being a local variable, parameter, or static member.
The explicit this. prefix follows a common coding style preference in Java codebases.

Anything in particular you'd like reviewers to focus on?

I wound up writing quite a bit of code to determine whether we're looking at a non-static field that's not already prefixed with this. Is there a better way?

Should I register the recipe in any suite? Should I add the recipe to common-static-analysis.yml (commented out initially)?

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

An alternative would be to make this configurable (e.g., only apply to fields, or only to methods), but starting with a simple "always add this." approach keeps the recipe straightforward.

Any additional context

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[greg-at-moderne]

Can you add a test with a typical setter implementation?
This is probably the most common example where of variable name shadowing. One being a field and another being a local.

[motlin]

Can you add a test with a typical setter implementation? This is probably the most common example where of variable name shadowing. One being a field and another being a local.

@greg-at-moderne I added tests for value = value in this constructor, and field = field in a setter. While these are "obvious" bugs - setting a parameter to itself - it was a deliberate choice not to replace these and the test shows they do not get replaced. The replacement would change semantics. It's not a bad idea to find and fix these but my preference is to separate recipes that may change semantics from recipes that perform pure refactorings and don't need much scrutiny. What do you think?