Fix event page regressions

This minor release fixes a regression: the title of the event page is not properly updated to reflect the application's name.

Step toward common event client code

This release changes the houselog module to implement a common client JavaScript code:

• Add a "proxy" item to the JSON responses (avoid having to query the proxy as a status request).
• Add JSON self-description ("app" array) to let generic code process the structure. Note that the overall design is intended to support in the future multiple lists of events, possible an aggregated from multiple sources.
• Move (most of) the JavaScript code in event.html to an event.js file, intended to be generic.
• Soon applications that use HousePortal will be changed to take advantage of the new event.js: change event.html and rebuild.

Improve event reporting

This release includes the following changes:

• Support services that have a static configuration (i.e. not updated by dynamic discovery)
• Add implicit events (more uniform events across services).

General improvements

Improvements in this release:

• Script to build a Docker container. This is more to play with Docker than for any practical reason.
• Improve on the discovery reaction time.
• Add a configuration module instead of duplicating one each time. That module will likely require more work, API is not necessarily stable yet.
• Minor CSS fix for configuration pages (add style for entry elements in table).

Maintenance release

Improve usability of the portal's main web page

Builds with echttp v1.4 (OpenSSL).

Full discovery mechanism and web UI

This release brings a full discovery mechanism, with a client module that provides a simple API. It also introduces a minimal web UI.

Some API have changed, mostly discovery and events.

Add new event and trace recording API

The main change in this release is the addition of a new API for event and trace recording. There are also a few documentation updates and bug fixes (release getaddrinfo data to fix memory leak).

The goal of the new API is to allow all applications in the House series to record historical information of interest to the end-user (events) or to the system administrator (traces) in similar ways and formats.

The events and traces are saved to files in /dev/shm, and then to permanent storage. The rationale for this two-stage approach is to avoid applications to write small amount of data to SD cards continuously, wearing them down (e.g. Raspberry Pi). Storing files to /dev/shm makes it possible to save the data between application restart, but still write to permanent storage only once in a while.

The houseportal application itself uses this API for its own recording, but please realize that there is no end-user to the houseportal application really, since the portal is meant to be transparent to the users. This makes houseportal not such a great example of the semantic difference between events and traces.

Allow live edit of the configuration

This release contains the following changes:

• If the configuration file is edited, HousePortal will reload the new configuration within 30 seconds.
• HousePortal prunes out any live redirect for which the latest renewal was received more than an hour ago.

First complete version

This is the first complete version, which I believe fully implements the behavior described in README.md.