Consider task analyzer/fixer advising helper methods to take AbsolutePath

Consider a task implementation that uses a helper method, like this trivial one:

```c#
public class MyTask : Task
{
[Required]
public string Input {get; set;}

public bool Execute()
{
return Helper(Input);
}

private static bool Helper(string input)
{
return File.Exists(input);
}
}
```

When making this multithread-aware, we'd like to get an `MSBuildTask003` at the `File.Exists` call, because we need to use a thread-aware path instead of relying on CWD. But the straightforward fixer (wrap to `File.Exists(TaskEnvironment.GetAbsolutePath(input))`) won't work, because the `TaskEnvironment` property is not available in `static` context.

But there's another possible fix, which is "make the static method take an `AbsolutePath` and push creating it elsewhere":

```diff
+ [MSBuildMultiThreadableTask]
public class MyTask : Task
{
[Required]
public string Input {get; set;}

public bool Execute()
{
- return Helper(Input);
+ return Helper(TaskEnvironment.GetAbsolutePath(Input));
}

- private static bool Helper(string input)
+ private static bool Helper(AbsolutePath input)
{
return File.Exists(input);
}
}
```

This isn't necessarily applicable everywhere but would be a nice suggestion in many cases.

Ideally it could also be used to build a barrier between "MSBuild task" code and "helper code" where we could establish guarantees about the absolute-ness of paths passed to "helper code" and not require that the helpers internally use `AbsolutePath`, since they may be shared with another non-MSBuild use case.

Start with the task analyzer/fixer behavior for MSBuildTask003 and trace how it handles File.Exists calls inside static helper methods. Compare the direct TaskEnvironment suggestion with the AbsolutePath parameter approach; done means the analyzer can recommend a valid fix where applicable without requiring TaskEnvironment in static context.

Written by the indexing model from the issue text.