We expect the viewer-manager package to be self-contained: we expect it to
bring with it any Python packages it requires. We no longer force developers
to wrap third-party Python packages as autobuild packages.

This avoids having to tokenize a single string, avoiding swallowing
backslashes in Windows pathnames in the mistaken belief they're escape
characters. Alternatively, it avoids us having to double-escape them or
convert them to forward slashes or whatever.

Clearly it's not obvious to maintainers that on the Mac, getAppRODataDir()
returns the app's Resources directory: in a number of places the code starts
with the executable directory and appends "../Resources" to find that.

But change shortcuts and registry entries and everything else back to the real
viewer executable, so that every subsequent run directly launches the viewer.

Eliminate SL_Launcher references from viewer_manifest.py.

codesign claims to succeed, but spctl says:
/Volumes/Second Life Installer/Second Life Test.app: rejected
(the code is valid but does not seem to be an app)

Why not? Display what's in Second Life.app/Contents on the mounted
sparseimage: show Info.plist, list Frameworks, MacOS, Resources.

The start of viewer_manifest.DarwinManifest.construct() is a path() call to
copy the whole viewer tree from where CMake constructs it. The comment is:
"(this is a no-op if run within the xcode script)." Unfortunately, for unclear
reasons, this has recently started nesting Second Life.app within the Second
Life.app directory, and even to multiple levels. When that happens, copying
the outermost .app directory to the sparseimage in order to convert to dmg
runs out of room because we're trying to pack multiple copies of the whole
viewer tree into the fixed-size sparseimage.

But if it works to simply skip that entire initial copy operation, so much the
better.

We'll try to address the Mac app bundle name discrepancy a different way.

The relationship to MAINT-9047 is that we hope this will improve the behavior
of Mac code signing.