Refactor path handling. Prefer absolute paths wherever possible.

[dfederm]

Today paths are handled in a haphazard way, somewhat as a holdover from QuickBuild combined with the logic used to make paths portable.

Previously a "normalized" path was either repo-relative, or had placeholders, depending on context. Also, most paths were repo-relative, which is causing problems now that we're trying to do more with other paths outside the repo, like paths in the NuGet package cache.

This change rationalizes things by defining the following wrt paths:

• "Absolute" paths are full rooted paths. This form is preferred in most cases.
• "Relative" paths are relative to the repo root. This form is mostly used with outputs since we (probably) will never consider outputs outside the repo, and also where it makes sense like for logging a project file path.
• "Normalized" paths are absolute paths with well-known base paths replaced with placeholders, eg the repo root or the nuget package cache. This form is used in logging to make log files more easily diffable, as well as in cached metadata to make paths portable across machines.

Additionally, BXL's AbsolutePath adds a long path prefix (\\?\) to long paths automatically, which messes with some of our string manipulation. For ease of use, I've avoided all usage of AbsolutePath except just before talking to the BXL APIs which require them. The alternative would be to use AbsolutePath literally everywhere and add some helpers to their code for things like making relative paths, but I feel like tying so strongly to BXL's concept of paths isn't a great idea, especially since this project generically (barring specific impls) should not really be strongly tied to BXL's cache code at all. It is today unfortunately due to the local cache, but one day I hope to break that.

[dfederm]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).