Snapd feature request for my Docker image that many people rely upon for CI/CD

Recent changes to snapd caused my Docker container image of snapcraft to break per https://github.com/diddlesnaps/snapcraft-container/issues/8

I have found a workaround that does not require any changes to snapd by forcing snapd to believe it is running in WSL. I have done this by replacing `systemd-detect-virt` with a script that returns the hard coded response of `wsl` per my PR at https://github.com/diddlesnaps/snapcraft-container/pull/17 (specifically https://github.com/diddlesnaps/snapcraft-container/blob/168ad01449f35e66654b047ca3ca676c8840e79e/systemd-detect-virt and https://github.com/diddlesnaps/snapcraft-container/blob/168ad01449f35e66654b047ca3ca676c8840e79e/Dockerfile#L55).

This is picked up by snapd at https://github.com/snapcore/snapd/blob/185fb2c8b1fab8e07db22f9af9af251a6d912ed5/cmd/snapd-apparmor/main.go#L83. This is obviously not a futureproof method of ensuring that my container image continues to function should WSL changes necessitate snapd drop the wsl bypass.

Therefore I would like to request that snapd include a way of forcing the isContainerWithInternalPolicy function to return true based on some method that I can implement in my container image - like overriding the systemd-detect-virt executable as I'm already doing with the hack in my PR to return wsl. The easiest method is to add an extra check identical to the wsl one but which checks for a different specific string returned from systemd-detect-virt e.g. "Do as I say!" that is unique enough that systemd-detect-virt will never implement it so that we can be sure that this bypass can ONLY be used by someone who knows about it. As /usr/bin/systemd-detect-virt is root-owned then this should not be a security issue IMO, but it would be good to get the security team to weigh-in on this method and whether there would be a better method that I could use.