Don't run build-sync-wheels as root

Currently running build-sync-wheels as root will cause issues for
different, subtle reasons.

First, you can't unpack idna-3.2.tar.gz as root with tar. For some
reason it uses very large uids/gids. When tar is run as root, it tries
to restore the original file owners, which doesn't work because those
large uids/gids are bigger than an unsigned 32-bit integer.

Note that repacking the upstream tarball isn't an option because we are
testing reproducibility against the source tarball hosted on PyPI. I've
asked upstream if they can fix this going forward at
<kjd/idna#123>.

The workaround for tar is to use `--no-same-owner`, so the files will
end up owned by the current user, aka root:root. This allows unpacking
to succeed, but for some reason, it causes very subtle reproducibility
differences in the built Python wheels. I've posted diffoscope output to
<https://gist.github.com/legoktm/d8a9209dbf94bb3a8939828a609fd2c4>,
various metadata files have the group writable bit set when previously
it wasn't.

Theoretically we could rebuild all of our wheels to be in this
configuration, except that's a lot of unnecessary work and it would
likely mean that everyone has to build wheels as root going forward.
That's risky unless you're properly using rootless containers, so it's
easiest to just tell people they need to run this script as a non-root
user.

scripts/build-sync-wheels

@@ -11,6 +11,12 @@ import argparse
 from pprint import pprint
 
 
+if os.geteuid() == 0:
+    # tar has issues when resetting permissions and ends up
+    # causing very subtle reproducibility issues.
+    print("This script cannot be run as root.")
+    sys.exit(1)
+
 # Set SOURCE_DATE_EPOCH to a predictable value. Using the first
 # commit to the SecureDrop project:
 #