Integrate health check functionality

Thanks @anybody, I like the idea and I think it makes sense here. It shouldn't be enabled by default though: I'd go for a checkbox in the audit settings that exposes the route, so whoever needs it turns it on and points their monitoring service at it.

I'd rather postpone this until #3606303 is merged. The health check should just read that value and return an error when the audit isn't fully green (or above whatever threshold we end up making configurable), not calculate anything on its own.

One thing I'm clear about for the implementation: the route itself must not be cached, no page cache and no dynamic page cache, because the point is to verify the request actually reaches Drupal. The audit result behind it should come from cache though, we already invalidate it in #3606303 when any of the affected config changes. health_check is a good reference for the route part, it shouldn't be much work.

I've implemented this as a new submodule, Audit: Health Check (audit_health_check), instead of adding it to the config checks. Enabling the submodule is what creates the endpoint, and it's built so other audits can be added later. It isn't part of Audit: All, so nobody gets a new URL without enabling it explicitly.

The endpoint is /audit/health. It answers 200 OK when everything passes and 503 FAIL otherwise, so monitors and load balancers only need the status code. It currently checks:

• Config checks: the audit score against a configurable minimum (100 by default).
• Database: it answers a trivial query, which matters when pages can be served from Redis without touching the database.
• Cron: it ran within a configurable number of hours (24 by default).
• Files: the public and, if configured, private files directories are writable.
• Cache: the default cache backend can store and return data, which catches an unreachable Redis or Memcache server.

Each check can be turned off in the audit settings page, under "Health check endpoint", which also shows the full URL to give to the monitor. Two more checkboxes control the answer: the time it was generated (on by default, handy to spot a CDN or proxy caching it) and one line per check with OK/FAIL and a short detail such as the score against its minimum (off by default, meant for debugging). The details never say which setting or module is wrong; the audit report does.

For privacy and security, the endpoint always requires a secret passed as ?secret=.... It's generated on install, can't be left empty, and any request without the right secret gets a 404, as if the route didn't exist. The response is never cached, by Drupal or by external caches. It also keeps answering in maintenance mode, so a load balancer doesn't drop every instance during a deployment, and it isn't redirected by the Redirect module.

This is already in the development branch (1.x-dev), so I'm marking the issue as Fixed. It will be included in the next stable release.