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).

Don't assume the supervisor is a registered process.

Replaced another use of element(2,Pid). Added some tests with somepid instead {local,name} as supervisor reference

Improve lager_console_backend to support non-atom output log levels.

This supports forms such as "!notice" for configuring the output
log level (using the config handling changes from 7aa31690).

Lager doesn't print iolists with ~s right

Parse transform can't handle `Attr' as a variable

Empty registered processes section in lager.app.src.

As long as *one* of the arguments is a literal, lager can figure out
what you're trying to do and (re)arrange the arguments as necessary.

Tracing without using parse transform.

add whitelist of error_logger handlers not to delete when error_logger_r...

This helps systools detect registered name clashes

Support pretty printing records found in a module at compile time

Support backend modules defining their own gen_event handler ID

Reject invalid format strings more aggressively

BUGFIX: Avoid overloading the LOG macro.