1. Add set_high_water/1 to adjust the high water mark after startup
2. Add test func t0/0 to demo (interactively only, sorry) that the
   limiting is working as we expect).
3. Remove a couple of comments.

Implement a new config option error_logger_hwm, which is a number
representing how many messages per second we should log from the
error_logger. If that threshold is exceeded, messages will be discarded
for the remainder of that second.

This is only effective if lager itself can process the messages fast
enough to satisfy the threshold. If your threshold is 1000 and lager
itself is only writing 100 messages a second (because error messages are
causing fsyncs or whatever) you'll never exceed the threshold and drops
will never happen. Thus care needs to be taken when selecting this
feature.

Setting it low is not as bad as it might seem, because when using lager,
hopefully error_logger messages are unusual. In my testing, 50/second
with the default config seemed reasonable (which has 2 file backends
installed, both of which fsync on messages at error or above).

Whenever we have the filename we ALWAYS have the module name, which is
effectively just as useful and already printed.

Tests now pass on both R15B and R14B03.

Since the lager_format rewrite, ~p and ~w now have different behaviour
with regard to printing lists as strings.

Before this fix, the code assumed that processes without a registered
name omitted the {registered_name, X} tuple in the crash report. In
actual fact, process_info/2 returns [] when the process has no
registered name, so unregistered processes were being printed with a
"name" of "[]". This corrects the code to print the Pid in this case
instead.

As Ryan pointed out, the 'name' of a supervisor's child may be
'undefined' for a simple_one_for_one supervisor.

The ~w formatting used before was not printing lists embedded in other
terms. This change uses trunc_io to print those terms safely and without
potentially introducing linebreaks (like ~p would)

IBM punchcards rejoice! Basho supports your right to continue to affect
how we format source code :)