Add a `buildContext` option to Platform in Manifest

[lbussell]

By default, ImageBuilder uses an explicit build context of the Dockerfile's location:

docker-tools/src/Microsoft.DotNet.ImageBuilder/src/ViewModel/PlatformInfo.cs

Lines 59 to 62 in 14b1496

	string dockerfileWithBaseDir = Path.Combine(baseDirectory, model.ResolveDockerfilePath(baseDirectory));
	DockerfilePath = PathHelper.NormalizePath(dockerfileWithBaseDir);
	BuildContextPath = PathHelper.NormalizePath(Path.GetDirectoryName(dockerfileWithBaseDir));
	DockerfilePathRelativeToManifest = PathHelper.TrimPath(baseDirectory, DockerfilePath);

In some cases it's desirable to access content from outside the Dockerfile's directory. For example, when building .NET projects, you may need to access a Directory.Build.Props or NuGet.config located in a parent directory.

There are two ideas I came up with for implementing this:

Option 1: explicit path

This option would allow you to set the explicit path to the build context. The path would be relative to the manifest.

{
  "dockerfile": "src/ImageBuilder/Dockerfile.linux",
  "buildContext": "path/to/my/preferred/context",
  "os": "linux",
  "osVersion": "azurelinux",
  "tags": {
    "linux-amd64": {},
    "linux-amd64-$(UniqueId)": {}
  }
},

Option 2: limited choices

The other option would allow you to choose between having the build context be the Dockerfile's parent directory (the default, today) or the manifest's parent directory. This could be via an enum:

{
  "dockerfile": "src/ImageBuilder/Dockerfile.linux",
  "buildContext": "Manifest", // OR "Dockerfile"
  "os": "linux",
  "osVersion": "azurelinux",
  "tags": {
    "linux-amd64": {},
    "linux-amd64-$(UniqueId)": {}
  }
},

Or a boolean:

{
  "dockerfile": "src/ImageBuilder/Dockerfile.linux",
  "manifestRelativeBuildContext": "true", // "false" is the default
  "os": "linux",
  "osVersion": "azurelinux",
  "tags": {
    "linux-amd64": {},
    "linux-amd64-$(UniqueId)": {}
  }
},

[lbussell]

[Triage] The driver for this work is #1430. This is needed when combining projects into one solution file. Without it we can't utilize any Directory.Build.props or Directory.Packages.props files to share things between projects.