Pack ImageBuilder as dotnet tool

[lbussell]

This is related to #2006. Since ImageBuilder is only used natively on Windows (and not ran from inside a container image), I would like to explore distributing ImageBuilder as a tool instead of a container image for that platform. The central hypothesis here is that we could potentially remove the Windows build leg of ImageBuilder entirely, drastically speeding up build and iteration time.

This PR only adds a new acquisition channel for ImageBuilder. It does not remove Windows container images or anything like that.

[mthalman]

The central hypothesis here is that we could potentially remove the Windows build leg of ImageBuilder entirely, drastically speeding up build and iteration time.

In January of 2027, Windows Server 2016 will be EOL. Dropping support for that would allow us to run ImageBuilder in a container just like we do for Linux because 2016 is the version that doesn't allow us to run nested containers. So that's only 9 months away. I'd rather keep the status quo until that point and then move forward with running ImageBuilder in a container in Windows. That will allow us to finally have a common pattern across both platforms.

[lbussell]

In January of 2027, Windows Server 2016 will be EOL. Dropping support for that would allow us to run ImageBuilder in a container just like we do for Linux because 2016 is the version that doesn't allow us to run nested containers. So that's only 9 months away. I'd rather keep the status quo until that point and then move forward with running ImageBuilder in a container in Windows. That will allow us to finally have a common pattern across both platforms.

Trust me, I too am counting the days until Server 2016 EOL.

However, the latest ImageBuilder build took 1 hour and 27 minutes. Whereas it takes literally 40 seconds to do a fully clean restore + build + test + pack of this repo on my laptop. It is not an exaggeration to say that we could ship changes 10x or even 20x faster by ditching Docker-in-Docker.