The application zygote is a new sort of zygote process that is a
child of the regular zygote. Each application zygote is tied to the
application for which it's launched. Once it's started, it will
pre-load some of the code for that specific application, much like
the regular zygote does for framework code.

Once the application zygote is up and running, it can spawn
isolated service processes that run in the isolated_app domain. These
services can then benefit from already having the relevant
application code and data pre-loaded.

The policy is largely the same as the webview_zygote domain,
however there are a few crucial points where the policy is different.

1) The app_zygote runs under the UID of the application that spawned
   it.
2) During app_zygote launch, it will call a callback that is
   controlled by the application, that allows the application to
   pre-load code and data that it thinks is relevant.

Especially point 2 is imporant: it means that untrusted code can run
in the app_zygote context. This context is severely limited, and the
main concern is around the setgid/setuid capabilities. Those conerns
are mitigated by installing a seccomp filter that only allows
setgid/setuid to be called in a safe range.

Bug: 111434506
Test: app_zygote can start and fork children without denials.
Change-Id: I1cc49ee0042d41e5ac6eb81d8f8a10ba448d4832