Post-mortem debugging from assertion failures

#143 describes how to make our assert()s more helpful for users and us upstream trying to triage issues. Often though, the response to a bug report is asking the reporter to re-run the same scenario with more logging information, sometimes with bespoke add-more-logging patches. This might be difficult, especially if the issue only happens intermittently and would require gigabytes of log data to be generated.

Since we already generate log data with the debug infrastructure from #133 (closed), it would be great if we could selectively enable post-mortem debugging where:

• all (or selected) debug scopes were active all the time regardless of whether or not there was an active streaming client
• an internal client was created always recording these scopes into a ring buffer
• on assertion failure, these ring buffers would all be dumped, along with any head information required (e.g. the timeline scope would need to be preceded by a dump of all available objects)
• to debug things which don't trip asserts (e.g. screen blinks unpleasantly, glitch observed in animations, whatever), a debug hotkey was available which would dump the last available debug data for later analysis

The internal stream 'client' might also be useful for simplifying the implementation of Weston's 'log' scope, and allowing other scopes to be captured. For example, there is no way currently to capture output from the drm-backend during startup.