JS_STANDALONE builds don't need everything in mozglue; have mozglue omit the
unneeded code for such builds.
Since the SpiderMonkey binaries are now more like the other Gecko binaries, we
can remove some special cases for JS_STANDALONE in GeckoSharedLibrary,
GeckoProgram, etc. All Gecko binaries now use mozglue, which contains mfbt, so
we no longer need mention mfbt explicitly.
Add a property to the getBuildConfiguration testing function's result that
indicates whether we're using jemalloc or not.
Include the newly necessary source directories in the SpiderMonkey source
package.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
Support of zygote-like process forking is done as:
* The b2g chrome process forks a child process that will be the template for forking other content processes.
* The template process starts running to some point and freeze.
* When ready, the chrome process starts requesting the template to fork content proceses.
* The content processes forked from the template process recovers its states including the threads, file descriptors for epoll, signaling and IPC.
Recovery of the process states are done by wrapping some system and pthread calls to record the states in the template process and recover in the forked content process.
