Really fix updates when not running as root.

The problem is, Linux capabilities are not inherited through exec() unless either:
a) A special attribute is set on the executable file which states that it is allowed to inherit capabilities. This attribute can only be set by root, which makes it useless to us.
b) The process's UID is, numerically, zero.

Previously, in our UID namespace, we did not remap our UID to zero. Therefore, when exec()ing the new binary after an update, all capabilities to the UID namespace were lost. This means the newly-updated Sandstorm no longer had the ability to set up a new mount namespace, etc. It could create a new user namespace to solve this, but the nesting would just get deeper with every update, which would be bad.

So now we remap ourselves to zero, and it all works.

Reminder: Linux/POSIX capabilities are not object capabilities and are therefore nothing like Sandstorm/Cap'n Proto capabilities. Linux/POSIX capabilities are one of the worst-designed security mechanisms I've ever had to deal with. They are literally worse than useless:
* Nearly every Linux capability can be used somehow to escalate yourself to root, so they provide no actual security benefit vs. the old-fashion superuser approach
* The rules around Linux capabilities, especially inheritance, are nearly impossible to use usefully. Unless you are root, it's practically impossible to actually hold on to a capability and usefully use it, because no one actually sets the proper file attributes, so merely exec'ing a program drops your capability set.
* Linux capabilities are ridiculously overcomplicated and the cognitive load they create wastes a lot of developer time.

PS. Here's a fun link to Andy complaining about Linux capability inheritance some time ago:
  https://lkml.org/lkml/2012/12/1/189