Allow failing when dropping privileges inside container

[fredizzimo]

Some programs like GDB launces a shell without additional privileges, so dropping the privileges can fail. In order to fix that allow failures when already running inside a container.

Note, that I also tried another approach, testing if the effecting privileges are already correct, however it go unreasonably complex since 'getgroups' is a bit unspecified. And I think ignoring the failures gets the same end result. I also checked the bash source for a reference and they do check for matching privileges, but on the other hand they never call setgroups so they don't need to deal with that.

It is unspecified whether the effective group ID of the calling
process is included in the returned list. (Thus, an application
should also call getegid(2) and add or remove the resulting
value.)

I also noticed that bash has a -p, privileged mode parameter that wsl-distrod should probably also support, but that's not implemented in this pull request.

-p Turn on privileged mode. In this mode, the $ENV and $BASH_ENV files are not processed, shell
functions are not inherited from the environment, and the SHELLOPTS, BASHOPTS, CDPATH, and GLO‐
BIGNORE variables, if they appear in the environment, are ignored. If the shell is started
with the effective user (group) id not equal to the real user (group) id, and the -p option is
not supplied, these actions are taken and the effective user id is set to the real user id. If
the -p option is supplied at startup, the effective user id is not reset. Turning this option
off causes the effective user and group ids to be set to the real user and group ids.

Fixes #22

[fredizzimo]

It seems like I spoke too soon. There's still something wrong, the main executable can now run. but when I try to set breakpoints before starting "Cannot access memory errors". When using control-c to add breakpoints once the program is running it works. however. And running without using wsl-distrod with -e /bin/bash is also fine.

I don't know the exact reason yet. But I'll try to figure it out.

Edit I found the issue and explained it in more detail in #22. Those workarounds can be done without this pull request, but I still think it's worth including, since the fix is more general,