core: introduce applicaton abstraction

This introduces an abstration for OSv processes, called
"application". It represents an execution of a single command. The
goal of having this is to have a uniform interface for managaing
processes on OSv. This class is responsible for tracking all resources
associated with a running application.

For example, this will be used to track termination callbacks which an
application can register and which will be executed when application
termination is requested.
core: track current application context

We need to know to which application current thread belongs so that we
can expose per-application APIs like termination callback registreation.

In the future this could be also used to decide which threads should
be terminated when application falls out of its main().
core: add support for requesting application's termination

Application can register as many callbacks as it wants. The callbacks
will be executed exactly once when after application termination is
requested. If callback is registerred after termination was already
requested it is executed immediately. This way we avoid races between
callback registration and termination.
core: introduce application::get_return_code()
core: sprinkle tracepoints around application management code
core: add application::get_command()
httpserver: add termination handler
core: request termination of detached commands before proceeding to shutdown

Letting commands run while we shut down may result in page faults due
to DSOs getting unmapped while in use. This is often the case with
httpserver. This change will make OSv trigger termination of detached
commands before it shuts down. The callback is supposed to cause the
application to return from its main() in a timely manner.
core: integrate osv::run with osv::application

osv::application models a process more accurately than osv::run and
hence it should be used instead in most of the places which currently
use osv::run. This change moves osv::run() logic into osv::application
and makes the run() variants create an application.

Because users of run() are expected to get informed whether
application was run or not we need to change the API so that
application() will thrown a launch_error, instead of aborting, which
can be then caught by interested parties. This has a nice feature of
propagating more details about why we can't run the application.
tests: add test for application termination requesting