Request procesing loop should be started in ready handler to avoid race
between go-routine start and context ready flag assignment.

The issue introduced in 43553aa72111.

Introducting application graceful stop.  For now only used when application
process reach request limit value.

This closes #585 issue on GitHub.

This is the port shared between all application processes which use it to pass
requests for processing.  Using it significantly simplifies the request
processing code in the router.  The drawback is 2 more file descriptors per each
configured application and more complex libunit message wait/read code.

The goal is to minimize the number of (pid, id) to port hash lookups which
require a library mutex lock.  The response port is found once per request,
while the read port is initialized at startup.

- Changed the port management callbacks to notifications, which e. g. avoids
the need to call the libunit function
- Added context and library instance reference counts for a safer resource
release
- Added the router main port initialization

An earlier attempt (ad6265786871) to resolve this condition on the
router's side added a new issue: the app could get a request before
acquiring a port.

Main process exiting before app process init may have caused hanging.