TryReadResponseFile masks nested response file resolution failures

[tannergooding]

TryReadResponseFile is implemented here: https://github.com/dotnet/command-line-api/blob/baf659198b043632e4a3cd70e0e3b8cd31c1efed/src/System.CommandLine/Parsing/StringExtensions.cs#L349-L395

It is effectively just calling ExpandResponseFile in a try/catch, which itself will recursively call ExpandResponseFile not in a try/catch.

What this means is that the top-most response file can succeed in resolution, but a nested response file might fail, which will in then report that the top most file was the point of failure.

---

Imagine you have:

WorkingDirectory
    ChildDir
        File1.rsp
    OtherDir
        File2.rsp

You then call Program @ChildDir/File1.rsp where File1.rsp itself contains @../OtherDir/File2.rsp.

You will get a failure of Response file not found 'ChildDir/File1.rsp, even though that file was found and it was ../OtherDir/File2.rsp which could not be resolved.

[tannergooding]

This, notably, also represents another issue, in that sub response files must be relative to the working directory and not relative to themselves. This effectively breaks the ability to include them correctly since users can launch your tool from any folder.

Some mechanism for allowing paths to be resolved relative to the containing response file would be beneficial.