(maint) Enable Docker VOLUMEs for LCOW

Part One

The first part of this PR was a crafty way to allow bind mounts to be used under LCOW, while allowing for named volumes to be used on Linux (for the same data - i.e. Postgres) without separate compose files:

Previously this value would be a path like c:\windows\temp\1234.hzs, but change it to have a trailing slash like c:\windows\temp\1234.hzs\
This makes the VOLUME_ROOT value useful as a PATH prefix in a volume declaration inside compose (making it a bind mount instead of a VOLUME), but still allowing for a named volume when it is missing.

For instance, assume the following in docker-compose.yml

   services:
     foo:
       volumes:
         - ${VOLUME_ROOT}foo:/tmp/bar

   volumes:
     foo:

On Windows, with VOLUME_ROOT set as c:\windows\temp\1234.hzs\ the evaluation is:

   services:
     foo:
       volumes:
         - c:\windows\temp\1234.hzs\foo:/tmp/bar

   volumes:
     foo:

A bind mount is used on Windows, instead of using the 'foo' volume which becomes extraneous (but harmless).

On platforms that don't have VOLUME_ROOT defined, the evaluation is:

   services:
     foo:
       volumes:
         - foo:/tmp/bar

   volumes:
     foo:

In this case, the named VOLUME 'foo' is used because a path is not specified (which would otherwise indicate a bind mount).

Carefully crafting this value allows for this flexibility across platforms, which is primarily useful for Postgres, which can only use bind mounts on Windows instead of VOLUMEs due to https://github.com/moby/moby/issues/39922

Part Two

The second part switches Azure / LCOW over to named volumes!

Turns out LCOW can use Docker VOLUMEs with Postgres!

As it turns out the problem was not one of bind mount vs VOLUME. Each LCOW VM vmwp.exe process (which in turn runs a single container) is assigned a randomized Windows user account in an effort to prevent VM breakout vulnerabilities.

Unfortunately the volumes that a container owns (created in C:\ProgramData\Docker\volumes) are not granted full access to that user, which is necessary for symlink creation. So it turns out it is a permissions issue, but the problem is on the Windows side, not the Linux side!
For now, we can work around this problem by running the following on every LCOW host that we use for testing (will also update the Pupperware docs accordingly):

icacls C:\ProgramData\docker\volumes /grant *S-1-5-83-0:"(OI)(CI)F" /T

All volumes created afterwards will inherit the F (FULL) permissions for the NT VIRTUAL MACHINE\Virtual Machines group (S-1-5-83-0).
This can't be done in each spec suite as the test runner agent runs a lower privilege account that can't change the permissions of files / directories within C:\ProgramData.
The reason this was never observed as a problem with bind mounts was due to ced39d78476272cee15e6810abf09a5526266b13 which grants the directory created for the bind mount with FULL access to all Users. This mitigates this problem (in the original case, auto-generated directories under the users temp directory, don't grant permissions to other users - so this allows the Docker process access to the path).
An issue has been filed in Moby to have the vmwp.exe process user associated with a given container granted full access to the volume paths it requires: https://github.com/moby/moby/issues/39922

Part Three

Update docs about LCOW + VOLUMEs

puppetlabs / pupperware