ws: Expose cockpit module resources via HTTP

This adds handlers under /res/ and /cache/ for loading cockpit
resources. These are served from data provided by cockpit-agent
and the resource1 channel payload.

In addition add code to load the full module listing including
manifests from a given cockpit-agent. We use this in the tests,
and in a later commit this is used to build the environment.
ws: Serve the / HTTP path with its own handler

Since the response to / cannot be aggressively cached, unlike almost
everything else ... include dynamic content right in the response to
minimize server round trips.

Removed the unused avatar data url. If we do want an avatar on
the login page, it should be retrieved as a normal image and have
its own handler.
ws: Add some debug messages to cockpit_web_response_file()
ws: Resolve static directory when testing handlers

This is because we have security checks to make sure that we don't
break out of the directory. Often the $srcdir that autotools generates
contains ../ and screws up these checks.
ws: Handle favicon.ico and apple-touch-icon.png separately

These don't get handled via /static or the later resource1
payload channel. These are special cases.
ws: Transfer login, module, host info using environment block

This is a JSON block called the environment which is used to pass the
necessary information to start up cockpit. It is received by the
javascript.

When not yet logged in, the environment contains very little
information, once logged in it is fully populated.

The environment is seeded in the '/' index handler, to avoid multiple
round trips. If a login occurs, then the full environment is transferred
as a response to the '/login' request.
static: Separate the login and boot code from shell module

We use the environment to load the cockpit-web as a single module
called 'shell'. This uses a simple module code, which is not
expected to be used to used with the later module loading.

In order to test this particular code you'll need to run:

ln -s /path/to/cockpit/src/web ~/.local/share/cockpit/shell
shell: Move cockpit-web into it a module called 'shell'

And install it to the appropriate location.

Note that we use a different manifest.json (with a combined
cockpit.js) when installed. This lives in the modules/shell/release
subdir.  The manifest.json that's in the modules/shell directory is
used while debugging.
ws: Remove http roots option for cockpit-ws

This is no longer used or relevant. Our HTTP resources come
from either the static directory or modules
test: Update tests for new module loading

Closes #708