Lager logs its own application start up message. Previously
this message was discarded or not received quickly enough
to cause test failures, but now it seems as though it
is being received and causing several test failures
even though we are explicitly flushing it away.

We introduce a 5 millisecond sleep for several tests
to make sure the start up message is received before the
flush command dumps it.

Lager logs its own application start up message. Previously
this message was discarded or not received quickly enough
to cause test failures, but now it seems as though it
is being received and causing several test failures
even though we are explicitly flushing it away.

We introduce a 5 millisecond sleep for several tests
to make sure the start up message is received before the
flush command dumps it.

The sync_error_logger file looks up the value to send from a process
dictionary entry named `warning_map' When it is unset, it uses a mapping
which is fine for OTP 17 and before, but 18 and 19 the value changed.

So now we put the current mapping value into the process dictionary so
that the messages do not cause failed tests.

During code review we decided that using Sink ++ '_lager_event'
would provide better isolation for gen_event names than
Sink ++ '_event' as we had been using up to this point.

For example a sink called 'audit' is now 'audit_lager_event'
than 'audit_event' which might clash with a user's predefined
own module or process name.

Previously, would fail due to lager:get_loglevel/2 not being exported.

Previously all messages were being flushed, which meant that trapped exits
and internal gen_event messaging was also flushed, leading to undefined
behaviour.

closes #198

Adds transparent event stream processing and statistics.
A new 3-tuple trace is introduced as `{Key, Op, Value}`, but
for backwards compatibility `{Key, Val}` implies `=` for `Op`
and `{Key, '*'}` remains as is in the case of wildcards.
A simplified query tree module is generated which reduces
redundant selection conditions to minimize filtering overhead.

This is done via a combination of several things:
* Make the loglevel that triggers a sync configurable
* Make the delayed_write size and intervals configurable
* Make the interval at which external rotation is checked for
  configurable
* Store the timestamp a lager_msg was created inside the lager_msg

To support these changes, several other things had to be modified:
* lager_msg:timestamp now returns a timestamp
* lager_msg:datetime was added to return the {date, time} of a message,
  like lager_msg:timestamp used to
* The configuration syntax for file backends was changed to be of the
  form {lager_file_backend, proplist()} and the old syntax was
  deprecated

Additionally, the defaults for the check_interval was raised from
'always' to 1 second, and the sync_interval was changed from 2 seconds
to one second.

For persistant processes with some immutable metadata (riak vnode and
the vnode ID, for example), implement lager:md/0 and lager:md/1 for
getting/setting such metadata into the process dictionary.

Such metadata is automatically included in any lager message metadata,
so you can just set it in your init() function or whatever and not have
to worry about passing the data around and using it in every lager call.

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.

Also, adapt the rest of lager to use this bitmask as well.

This also removes the dependency on the syntax_tools and compiler
applications, which interfered with lager's startup/shutdown order.

Helps with pattern matching.

I didn't want the lager_log_message record being used across application
boundaries, this will insulate other applications from any changes to
the message type's internal structure.