The strict configuration work in 31cf6c0 prevents some
backwards-compatible code in lager_file_backend from working as the
configuration is rejected before it gets to the backend. This fix adds
an additional guard on `check_handler_config/2` to support the `tuple`
configuration structure supported by `lager_file_backend`.

Introduces the option to have severity logged in uppercase letters, as is usual for other programs logging to syslog, for example.

Applications that explicitly configure lager's `crash_log` with the
value `undefined` will get a really terrible crash message for all
versions since 81222ca486

Diff here: 81222ca486 (diff-25e915f0df09d04052d2a6e85b8824f2)

That message looks like this:

```
** Generic server lager_crash_log terminating
** Last message in was rotate
** When Server state == {state,undefined,
                              {file_descriptor,prim_file,{#Port<0.1340>,15}},
                              281571,65536,10485760,
                              [{hour,0}],
                              5,false}
** Reason for termination ==
** {badarg,[{erlang,'++',[undefined,".3"],[]},
           {lager_util,rotate_logfile,2,
                       [{file,"_build/default/lib/lager/src/lager_util.erl"},
                        {line,220}]},
           {lager_crash_log,handle_info,2,
                            [{file,"_build/default/lib/lager/src/lager_crash_log.erl"},
                             {line,99}]},
           {gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,601}]},
           {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,667}]},
           {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
```

This fix will allow people who use this legacy configuration to not
experience production crashes at midnight after the deploy, when
crash_log tries to rotate for the very first time, resulting in trying
to append `.Int` to `undefined`

* Make lager_handler_watcher test more resilient by scanning for
  messages of interest rather than assuming we know exactly what
  messages will arrive at the test backend

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.

Previously, was always hardcoded to the default sink name.

Previously, configuration would come from application:get_env/3 or
proplists:get_value/3. Now we standardize on a single format
for retrieving values from the environment or from a proplist.

Signed-off-by: Brian L. Troutwine <brian.troutwine@adroll.com>

This is, perhaps, not the most ideal setup. It still ignores other
sinks but does bring logging back online after the appropriate delay.

Signed-off-by: Brian L. Troutwine <brian.troutwine@adroll.com>

At this point in the work, the killer will correctly stop the
DEFAULT_SINK in the event of overload but our friend never comes back
up and lager stops working past this point.

Oops!

Error message:

=SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 ===
     Supervisor: {local,lager_handler_watcher_sup}
     Context:    child_terminated
     Reason:     killed
     Offender:   [{pid,<0.63.0>},
                  {id,lager_handler_watcher},
                  {mfargs,{lager_handler_watcher,start_link,undefined}},
                  {restart_type,temporary},
                  {shutdown,5000},
                  {child_type,worker}]

=SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 ===
     Supervisor: {local,lager_handler_watcher_sup}
     Context:    child_terminated
     Reason:     killed
     Offender:   [{pid,<0.59.0>},
                  {id,lager_handler_watcher},
                  {mfargs,{lager_handler_watcher,start_link,undefined}},
                  {restart_type,temporary},
                  {shutdown,5000},
                  {child_type,worker}]

=PROGRESS REPORT==== 10-Mar-2016::16:18:11 ===
          supervisor: {local,lager_sup}
             started: [{pid,<0.113.0>},
                       {id,lager},
                       {mfargs,{gen_event,start_link,[{local,lager_event}]}},
                       {restart_type,permanent},
                       {shutdown,5000},
                       {child_type,worker}]

Signed-off-by: Brian L. Troutwine <brian@troutwine.us>

Addresses #291. External consumers who use 'none'
as a level in their log messages will fail dialyzer.

Address #286. This will enable applications to
dynamically configure log sinks, provided they
have already instrumented the code via parse
transformation to use those sinks.

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.

Previously, was always hardcoded to the default sink name.

Previously, configuration would come from application:get_env/3 or
proplists:get_value/3. Now we standardize on a single format
for retrieving values from the environment or from a proplist.

Signed-off-by: Brian L. Troutwine <brian.troutwine@adroll.com>

This is, perhaps, not the most ideal setup. It still ignores other
sinks but does bring logging back online after the appropriate delay.

Signed-off-by: Brian L. Troutwine <brian.troutwine@adroll.com>

At this point in the work, the killer will correctly stop the
DEFAULT_SINK in the event of overload but our friend never comes back
up and lager stops working past this point.

Oops!

Error message:

=SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 ===
     Supervisor: {local,lager_handler_watcher_sup}
     Context:    child_terminated
     Reason:     killed
     Offender:   [{pid,<0.63.0>},
                  {id,lager_handler_watcher},
                  {mfargs,{lager_handler_watcher,start_link,undefined}},
                  {restart_type,temporary},
                  {shutdown,5000},
                  {child_type,worker}]

=SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 ===
     Supervisor: {local,lager_handler_watcher_sup}
     Context:    child_terminated
     Reason:     killed
     Offender:   [{pid,<0.59.0>},
                  {id,lager_handler_watcher},
                  {mfargs,{lager_handler_watcher,start_link,undefined}},
                  {restart_type,temporary},
                  {shutdown,5000},
                  {child_type,worker}]

=PROGRESS REPORT==== 10-Mar-2016::16:18:11 ===
          supervisor: {local,lager_sup}
             started: [{pid,<0.113.0>},
                       {id,lager},
                       {mfargs,{gen_event,start_link,[{local,lager_event}]}},
                       {restart_type,permanent},
                       {shutdown,5000},
                       {child_type,worker}]

Signed-off-by: Brian L. Troutwine <brian@troutwine.us>

Otherwise `lager_transform` fails after de9012628a

The error message is:

    test/pr_nested_record_test.erl: error in parse transform 'lager_transform': {function_clause,
                                                 [{lager_transform,
                                                   '-walk_ast/2-fun-0-',
                                                   [{typed_record_field,
                                                     {record_field,5,
                                                      {atom,5,field1}},
                                                     {type,5,term,[]}}],
                                                   [{file,
                                                     "src/lager_transform.erl"},
                                                    {line,62}]},

If expand_path/1 already contains LogRoot in its RelPath, do not
add it again.