In order to be able to run both old-configure and js/src/old-configure
from the same python configure run, we need to stop setting the items
set by old-configure into the global sandbox config, and instead store
them to be later handled by configure.py.

It wasn't normalized early enough to end up in config.status. It is
surprising this hasn't caused problems earlier.

This simplifies how js gets zlib by simply using the zlib Library
defined in config/external/zlib instead of manually adding MOZ_ZLIB_LIBS
that it needs to inherit somehow correctly from the top-level configure.

The use in browser/app was redundant with mozglue depending on zlib
already.

It is only really used in js/src/devtools/rootAnalysis/Makefile.in,
and even there, the way it is used seems wrong, so fix that at the
same time (binaries have been linked into $DIST/bin directly for a
while).

Preparing to run both old-configure and js/src/old-configure from the
same python configure run, we refactor things such that shared parts are
separate.

This helps reduce the diff size for subsequent patches.

That hasn't actually been necessary for a very long time.

Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.

Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.

When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.

Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.

One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.

It was only meant to be used internally, when the top-level python
configure invoked the js python subconfigure. Now that this doesn't
happen, we can remove the option, and consolidate js_standalone and
building_js, which are now roughly synonyms.

https://hg.mozilla.org/mozilla-central/rev/f9b1e7a5b6ee
https://hg.mozilla.org/mozilla-central/rev/261ea39c0758
https://hg.mozilla.org/mozilla-central/rev/51743cdf9c63
https://hg.mozilla.org/mozilla-central/rev/0ff51d71f0c0
https://hg.mozilla.org/mozilla-central/rev/0d3e42d60028
https://hg.mozilla.org/mozilla-central/rev/c233e3e55972
https://hg.mozilla.org/mozilla-central/rev/70d4c7957958
https://hg.mozilla.org/mozilla-central/rev/8b4ab5dd4446
https://hg.mozilla.org/mozilla-central/rev/b0b0edc7fde0