fix: prevent removal of static field import

[algomaster99]

The failing test case reproduces ASSERT-KTH/sorald#602.

[algomaster99]

The handleTargetedExpression ignored instances of CtFieldRead. This caused the removal of import statements which imported static fields. I have added a method isReferenceToFieldPresentInImports which checks if the field reference is present in imports, and if it does, it is added to computedImports.

[algomaster99]

@slarse @MartinWitt @monperrus could you please look at this?

[algomaster99]

At another glance, I think the fix should belong here. I am unsure about it though.

---

There are two ways to fix this problem.

1. Ensure import static fieldImport.UtilityLibrary.FirstUtility.LIMIT; is added to computedImports so that it is not removed later in onCompilationUnitProcessed.
2. Add a condition in onCompilationUnitProcessed which will not remove the import statement from exisitngImports even if it does not exist it computedImports.

This PR implements the 1. I don't know about the contract of the computedImports so I can't really pin-point which is the correct method to go about.

---

2. Add a condition in onCompilationUnitProcessed which will not remove the import statement from exisitngImports even if it does not exist it computedImports.

Second approach doesn't seem correct to me. The contract of onCompilationUnitProcessed seems like that it removes imports from existingImports if it cannot find it in computedImports. Therefore, a better way to fix this bug to go with 1 and this PR does exactly that.

[monperrus]

Cool! Do we need the three changes at line 90, 179 and 196 to fix the single failing test case?

[algomaster99]

Yes. Let me explain it case by case.

Line 90

This allows the instance of FieldRead to be passed to addImport.

Line 179

Since we are not in addImport (courtesy of line 90), we need to do something about it. This conditions checks if the ref is present in any of the import statements. If it is not present, we return so that the import is not added to the final output.

Line 196

This bit is quite tricky, but I have two reasons to support this diff.

1. When the import, import static fieldImport.UtilityLibrary.FirstUtility.LIMIT;, is present, we move forwards to check other conditions if it needs to be added in computedImports. The previous condition, without my diff, passed because package of the compilation unit and the field reference were same. We need to pass this condition when the references to types are considered.
2. The comment below the line changed further supports the diff because we only need to check for TypeReferences in same packages and not field references.

[monperrus]

Thanks for the explanation, merging.