feat(#556): auto-fix architecture

[Marat-Tim]

1. I didn’t find any clear standard format for describing code fixes, so I went with the LSP DocumentChanges format. It’s reasonably clean, supports all kinds of edits, and integrates well with our LSP server. For eoc, though, we’ll likely need to parse and apply changes manually(question). Hopefully, it won’t be too complex

2. I originally planned to use the lsp4j library, hoping it would support easy (de)serialization. But it uses a complex GSON setup, and gson-xml failed to handle it. So I decided to recreate the DocumentChanges structure with our own data classes

3. Added the fix package to hold data classes describing fixes

   3.1. Initially, I made all classes interfaces with Default implementations(similar to the Defect data class).
   But later realized that was overkill - no one would realistically extend these. So I switched to plain Java data
   classes. Now, creating a fix is simpler:

   new Fix(
     new File(
         new ObjectSource(xmir).get(),
         new Edit(
             new Position(line, 0),
             new Position(line + 1, 0),
             ""
         )
     )
   )

   instead of

   new Fix.Default(
     new File.Default(
         new ObjectSource(xmir).get(),
         new Edit.Default(
             new Position.Default(line, 0),
             new Position.Default(line + 1, 0),
             ""
         )
     )
   )

   3.2. I’m aware that we aim to keep the public API as minimal as possible, and a public fix package doesn't quite align with that. Still, putting all these classes into org.eolang.lints would look messy. Likewise, moving Fix to org.eolang.lints and nesting the rest as inner classes would be ugly. I considered keeping only interfaces and implementing them via anonymous classes where needed, but that would be too verbose. This might be worth a separate discussion here.

4. By default, linters still don’t offer fixes and behave as before. But to add fix support:
   4.1. For Java-based linters, just pass fix data into the constructor(like this)
   4.2. For XSL linters, move the message to a <message> tag and put the fix info in an <edit> tag(like this). I assumed XSL linters won’t need file creation or multi-file edits, so one edit per case should be enough

[Marat-Tim]

@yegor256 @h1alexbel I know the pipeline isn’t passing right now, but could you take a look at the idea behind it?
Do you like the overall direction, or is there anything you think should be changed?
If so, I'll make the adjustments and fix the pipeline

[github-actions]

🚀 Performance Analysis

All benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information.

Click to see the detailed report

Test	Base Score	PR Score	Change	% Change	Unit	Mode
benchmarks.SourceBench.scansXmir (size=S)	5659.689	5748.420	88.730	1.57%	ms/op	Average Time
benchmarks.SourceBench.scansXmir (size=M)	6217.782	6260.743	42.962	0.69%	ms/op	Average Time
benchmarks.SourceBench.scansXmir (size=L)	7317.458	7225.780	-91.678	-1.25%	ms/op	Average Time
benchmarks.SourceBench.scansXmir (size=XL)	8431.529	8299.239	-132.289	-1.57%	ms/op	Average Time
benchmarks.SourceBench.scansXmir (size=XXL)	20680.655	20847.601	166.947	0.81%	ms/op	Average Time

⚠️ Performance loss: benchmarks.SourceBench.scansXmir (size=S) is slower by 88.730 ms/op (1.57%)
⚠️ Performance loss: benchmarks.SourceBench.scansXmir (size=M) is slower by 42.962 ms/op (0.69%)
✅ Performance gain: benchmarks.SourceBench.scansXmir (size=L) is faster by 91.678 ms/op (1.25%)
✅ Performance gain: benchmarks.SourceBench.scansXmir (size=XL) is faster by 132.289 ms/op (1.57%)
⚠️ Performance loss: benchmarks.SourceBench.scansXmir (size=XXL) is slower by 166.947 ms/op (0.81%)

[h1alexbel]

@Marat-Tim maybe we should throw an exception in this case? Fix::new only will make things more complicated

[h1alexbel]

@Marat-Tim these classes should be package private. We don't want to expose them to the client

[h1alexbel]

@Marat-Tim File is a name of the well-known Java class. Let's rename this class to avoid confusion

[h1alexbel]

@Marat-Tim XMIR does not have @source attribute anymore, you should use org.eolang.parser.ObjectName instead

[h1alexbel]

@Marat-Tim to be honest, it is hard to review Fix architecture without unit tests. For now, I don't really understand how it works. So, I suggest to create unit tests, or even test YAML stories (the way we did in LtByXslTest#testsAllLintsByEo and WpaLintsTest#testsAllLintsByEo) to see how it works in practice (EO before fix vs. EO after fix).