Adds support for creating Windows scratch-equivalent baselayers

[micahyoung]

This allows FROM scratch-style Windows images (and buildpackages) to be stored on WCOW daemons (required for buildpacks/pack#840).

This is needed because imgutil in local scenarios requires all images to be stored on a Docker daemon. This works fine for Linux since the Docker daemon has pretty loose validation for Linux images (only requires the correct image metadata). But WCOW daemons, on the other hand, are most strict and require a specific baselayer as well. This difference is likely because there is no current FROM scratch use-case for Windows since it's not currently possible to statically compile a Windows binary with enough libraries to run in an empty container.

The smallest Microsoft-authored baselayer that can be stored on a daemon is from nanoserver, which is 100MB, has license restrictions for use, is a foreign layer that requires public internet access to pull, changes frequently due to patches, is coupled to the OS version (nanoserver:2004 images can't be pulled by Windows 1809), and currently has no long-term-supported version. For these reasons, it is unsuitable as a scratch-equivalent baselayer for something like buildpackages.

This implementation was derived from the files required by the moby and hcsshim codebases. It creates a layer with the 6 files necessary so an image that uses it can be stored on a daemon. There is no documented API contract for these files unfortunately which is a big downside. However the benefits in contrast to using nanoserver are that it can be generated on the fly on any OS, is created with OSS tools, has no distribution limitations, works with all current daemon versions, is only a few bytes, is trivial enough to hopefully not require regular patches, and if it does need to be patched, can be replaced with Image.Rebase(). The images with this layer can also be pulled and inspected with daemon-based tools like dive and presumably anything using the Docker API.

This implementation includes a new generator to create the imgutil source file with the encoded content of the most complex file - the baselayer's BCD hive file. This is needed only because the hivex C++ shared library is difficult to compile for OSes besides Linux and would introduce a surprising runtime requirement for consumers of imgutil on any OS.

I manually tested the layer against the main supported versions of Docker Desktop for Windows (1809, 2004) and Docker for Windows Server (1809, 2004). Additionally, a nearly identical layer has been used as an imgutil test fixture for the past several months without issue.

[micahyoung]

I realize I focused mostly on importance of this scratch base layer for imgutil scenarios. But in fact, any Windows OCI image must have some base layer like this one to allow docker pull, docker load, ggcr daemon.Write() or anything else that writes and image to a WCOW daemon, even if the base layer is not runnable.

A user who is not interested in using imgutil.Images could still benefit from using layer.WindowsBaseLayer with something like ggcr mutate.AppendLayer(empty.Image, tarball.LayerFromReader(layer.WindowsBaseLayer()))

Or something similar with a Docekerfile is also possible:

FROM mcr.microsoft.com/windows/nanoserver:1809 --as builder

RUN echo "created in Windows" > c:\output.txt

FROM micahyoung/scratch-windows

COPY --from=builder c:\output.txt c:\output.txt

[ekcasey]

@micahyoung Thanks for all of your hard work here. I appreciate the effort that went into creating the nice go generate interface.

I left some comments the mostly boil down to:

1. some very minor cleanup in the testhelpers
2. can we make the Makefile target smart enough to avoid slow generation steps when possible? If not maybe we should pull it out of the test target it leave it to users who edit the bsdgen code to run manually when appropriate?