Draft of incremental container generation

[baronfel]

Fixes dotnet/sdk-container-builds#438

This is a wholesale rewrite of the way that we generate container images to support better MSBuild incrementality (as well as controlling/caching the location that the SDK stores the pulled base image layers/manifests/etc).

In general, today we re-do a lot of work for each individual image:

• manifest pulling
• RID selection
• app layer creation
• app manifest/config creation
• publishing to various destinations

We do all of these things per-RID, every build.

With this PR we attempt to:

• pull manifests once (and support caching them!)
• pull layers once
• use the data from this stage as inputs to the rest of the container generation
• make the app-level layer, configuration, and manifest generation incremental
• separate the creation of the artifacts from the sending of the artifacts
• disentangle the giant ball of mud that CreateNewImage is :)

Right now, for single-RID containers we are very incremental! The main gaps are:

• rebuilds are missing some data (need input from @rainersigwald on the best way to ensure that Items created during Task execution are actually handled correctly across runs)
• the multi-arch manifest creation/publishing isn't yet created

[afscrome]

Could you use the last write timestamp of the main output assembly instead? That should be close enough to the actual date and is better than nothing.

I've found the created label very useful when troubleshooting people running latest tag, not realising it may not be the same latest as the container registry, so it would be a shame to loose it by default.