matchers: `fromPath` could be a literal (an actual path instead of a integer), or sibling to `owner`

@ericsciple this may be of your interest. I am trying to create a matcher for CMake. This is a sample of an error reported by CMake:

>cmake .
CMake Error at subdir2/CMakeLists.txt:7:
  Parse error.  Expected "(", got newline with text "

  ".


-- Configuring incomplete, errors occurred!

As you see the output does not contain the main CMakeLists.txt, but it contains a relative path to it.
Now if the main CMakeLists.txt file is not in the root of the repository, the path "root/subdir1/subdir2/CMakeLists.txt' will not be rooted by this code.

To make a matcher to work I think i need one of the following:
1- the fromPath property should be sibling to owner, a string that specifies the path to the main CMakeLists.txt;
2- the pattern[0].fromPath accepts either an integer, or a string, where the latter is the path to the main CMakeLists.txt;

This is a sample of the matcher that my run-cmake action is creating on the fly, but of course since 'fromPath' is not an integer, it will fail:

"problemMatcher":[
   {
      "owner":"cmake",
      "pattern":[
         {
            "regexp":"^\\s*CMake (Error|Warning) at (.+):(\\d+):",
            "severity":1,
            "file":2,
            "line":3,
            "fromPath":"/home/runner/work/CppBuildTasks-Validation/CppBuildTasks-Validation/matchers/cmake_error"
         },
         {
            "regexp":"^\\s+(.*)$",
            "message":1
         }
      ]
   }
]

Would one of those solution acceptable/feasible? I can add this feature.

Start with src/Runner.Worker/Handlers/OutputManager.cs at the linked path and trace how problem matcher fromPath values are interpreted. Compare the two proposed configuration shapes against the CMake example, then define and test the supported path behavior so relative CMake file paths are rooted correctly.