WCIFS/AttachLayerStorageFilter read-only mount support

This is a fairly speculative feature request, since it almost certainly requires OS-level support.

I was reminded by discussion in a containerd PR that the current best-known (by me...) approach to do a read-only mount of a committed WCOW container image on the host is to mount it as a read-write mount with a small-as-possible sandbox/scratch VHDX, and then discard that VHDX at the end.

Although workable, this suffers from two issues:

• Anything that tests the readonlyness will see a read-write layer; although this is a documented-valid implementation, the containerd Snapshotter test suite doesn't currently agree.
• We're spending time on VHD manipulation/mounting needlessly.

So the request is that either AttachLayerStorageFilter gain a parameter, or a new API be introduced, that would in-effect take just a layerData structure, with no layerPath, and resulting in a mountable volume GUID or whatever AttachLayerStorageFilter actually produces... (See #1076 where I documented that I have never used AttachLayerStorageFilter successfully, so am not totally sure what the expected flow is).

Looking at the user-space WCIFS and Bind Filter APIs introduced after RS5 (which I learned about via #1462), the tools for this might already exist at an OS level, in Windows Server 2022, if I'm guessing correctly that a Bind Filter merged mapping is the same as a WCIFS layer stack.

The other reason this is speculative is that I don't have a concrete use-case for this apart from "the containerd snapshotter tests this". I suspect BuildKit's COPY --from=<some_image> will hit this code-path, though, from minimal code-tracing efforts, as it relies on host-mounts, which is how that PR got started in the first place.

Start by tracing AttachLayerStorageFilter and the layerData flow, then compare the referenced WCIFS and Bind Filter APIs in NativeContainerUtilities.cs. Review the containerd snapshotter tests linked in the issue and determine whether a read-only mount API is available on the targeted Windows versions. Done means an agreed API design and validated mount behavior, but the issue does not define a concrete implementation path.