Rewrite docs for context locals, request contexts, and app contexts

Closes #1151.

The following is an incomplete draft. However, I wanted to request comments immediately, in case anything was severely wrong.

The doc should be updated to include:

- [x] How context-local objects in Flask are implemented

Will squash commits later.
I can't describe this problem very well, but i recognize it when i see it. My
story below is totally unrelated to Flask, but it *might* help anyways.

Here's a case where it came up for me, using [a CLI application written in
click](https://github.com/untitaker/vdirsyncer).

Click also has the concept of "contexts". Similarly to the request context, a
context in Click contains data related to the currently invoked command and
subcommand. It also provides something similar to ``flask.g``, but in this case
it's a single attribute ``ctx.obj`` that the user can set to any object. Click,
however, requires you to pass the context around explicitly. It's as if a view
function in Flask would get the request object as an argument.

    import click
    @click.command()
    def cli():
        click.echo("Hello World.")

    if __name__ == '__main__':
        cli()

Since for simple applications having access to the context might not be even
required, you'll have to explicitly ask for it by applying a special decorator
to the ``cli`` function. Even if you don't, it exists.

In the software i linked above, i wrote a synchronization tool. As its readme
suggests, it has storage objects which all implement a CRUD API, a common
interface defined in ``vdirsyncer.storage.base``.  This code (submodules in
``vdirsyncer.storage``) is separated from the CLI code, so the code that
implements the various storages doesn't even know or mention the concept of a
command line interface. It is, essentially, a library.

If you take a look at the example configuration, you'll see that the user can
basically use the various storage types to define storages. This config file is
used in the CLI code, and with a little bit of trickery, the parameters from
the config are more or less directly translated into keyword arguments passed
to the __init__ method of the storage class.

Now, some storages talk to remote services, and might require passwords. If the
user didn't specify a password, the program should ask for one. So we have the
following logic, where get_password looks through the system keyring or prompts
the user:

    if username and not password:
        get_password()

At first sight this code should go into the CLI module. But then, the CLI
doesn't know about the specifics of a storage. Maybe "username" is a completely
different concept for some storage types. The storage might accept usernames
without a password. Maybe the situation isn't clear until the server is
actually asking for a password. So instead we say that it is the storage's job
to do that.

Now we have the problem that the storage classes might be used as a pure
library, without a CLI surrounding it. Rare, but it might happen.  Prompting
for the user's password is not what a real library should do implicitly. It
might end up blocking the program, since the end user might not see the
console [1]. Since the storage classes don't know the concept of a CLI, how
should it know whether it actually should prompt for a password? If we only had
a global flag that indicated whether we are currently running as a CLI
application... OH WAIT.

* [1] This problem actually occured to me as a end user too. Synaptic (a
  package manager GUI for Debian) was suddenly hanging up. Turns out that
  aptitude (the actual package manager) was asking whether it should overwrite
  a config file i modified.