Address loss of symlinks and the libpython3.x.a symlink

We have this code in pythonbuild/utils.py:
```python
# The pax headers attribute takes priority over the other named
# attributes. To minimize potential for our assigns to no-op, we
# clear out the pax headers. We can't reset all the pax headers,
# as this would nullify symlinks.
for a in ("mtime", "uid", "uname", "gid", "gname"):
try:
ti.pax_headers.__delattr__(a)
except AttributeError:
pass

ti.pax_headers = {}
```
That last line is clearly inconsistent with the comment.

It also appearsa to be the case that we do in fact collapse symlinks, somehow, and this appears related to the fact that libpython3.x.a which is ordinarily a symlink into config/ is an independent copy of the same file.

I'm not actually sure our current behavior is wrong, to be fair, but if we're duplicating the file for no reason in a ZIP archive we should stop doing that, and this is probably a good opportunity to think about whether we want to ship libpython3.x.a in the install-only archives at all. The vast majority of our users don't need it, but some do (cf. Nuitka/Nuitka#3331).

I noticed this in the course of fixing a build failure in #827. Note that we have code in cpython-unix/build-cpython.sh that is commented ` # Symlink libpython so we don't have 2 copies.`, and then we promptly destroy the symlink.

This issue is to think more closely about what we're doing and why and make the comments and code all match some intended behavior.