Rework how dialyzer PLTs are built and used

This commit splits the PLTs into 2, one for all the required OTP
applications that are in the stdlib, and the other for the rebar
dependancies. Each one is created if it does not exist, then checked for
validity and then --add_to_plt is used to add any missing files (this is
very fast if nothing needs to be added). Then the application is
dialyzed using both PLTs.

The 'combo' PLT which resides in ~ is intended to be used by all of
Riak's deps, so it can grow to cover the set of OTP applications that
Riak depends on. Each project can only specify the ones it cares about.

Allow PLT destination to be specified

Fixed formatting.

Fix lager eunit initialization

Set source encoding so R17 compiler doesn't choke on lager_file_backend

Update rebar to support REBAR_DEPS_DIR

Fix doc of lager_console_backend

Clarifying how to disable 'crash_log'

The current set of instructions mention 'crash_log' being left undefined
as a variable to disable it, but when that happens, lager starts it at a
default location.

This commit makes it obvious that the value must explicitly set to
'undefined' in order to disable crash_log.

This reverts commit 6d7d1cc11d.

Update README: fix no_file error and config format error

Can't disable periodic file rotation

Add `async_threshold_window` option. #147

Removed incorrect ']}' from example config.

Documentation spelling fix.

Allow windows users to use the 'old shell' as there's no alternatives

Disable console backend if oldshell is used

Add ability for handlers to 'fatally' fail, so they won't attempt to
reinstall themselves later.

Also fix an issue with the INT_LOG macro not doing the right thing when
only the lager_throttle_backend was installed.

There's a nasty problem with the Erlang VM + lager when the old-style
Erlang console is used.  You can use the "-oldshell" flag to explicitly
get the old-style shell.  However, if the Erlang VM is started when
*not* associated with a pseudo-tty, the VM will silently use the
old-style shell (because the new-style shell requires a pty to
support command line editing, etc.).  The most common way of starting
the Erlang VM without a pty is to start it via a non-interactive
SSH session.

This patch is opinionated in what to do in the case when the old-
style shell is detected.  My opinion is:

1. Shout loudly to the console log (in a separate Erlang process, so
   that the main lager event handler proc won't be blocked by any
   problems with the old-style console).  It's almost certainly
   likely that you really don't want to run Erlang with the old-style
   shell.  But many sysadmins don't look closely at their systems'
   log files, so (for example) shouting the same message 10x in a row
   is legit.  Reviewers: YMMV.
2. Set a SASL alarm.  Again, many sysadmins' are bad at looking at
   log messages.  Setting a SASL alarm is another method to try to
   get their attention.

To test, create a test script called `/tmp/testit.sh`, changing the
`-pz` parameter to point to the correct place for lager's `ebin`
subdirectory:

    #!/bin/sh

    erl -pz /Users/fritchie/b/src/lager/ebin -eval '{application:start(sasl), lager_console_backend:init([error, true]), timer:sleep(5*1000), io:format("\n\nInfo: ~p\n\n", [{{alarms, alarm_handler:get_alarms()}, {user_drv, whereis(user_drv)}}]), erlang:halt()}.'

Then run it twice, using the following:

    First time: ssh -t localhost sh /tmp/testit.sh
    Second time: ssh localhost sh /tmp/testit.sh

The last lines of the first time should look like:

    Info: {{alarms,[]},{user_drv,<0.22.0>}}

The last lines of the second time should look like:

    Info: {{alarms,
               [{lager_console_backend,
                    "WARNING: old-style console is in use, so lager_console_backend log output to the console is disabled.  Restart the VM on a pseudo-tty to ensure use of the new-style VM console."}]},
           {user_drv,undefined}}