Avoid reliance on global state for authentication

When writing unit tests, we want to ensure each test is run in a "clean"
environment, devoid of any configuration or data left over from a
previous test. This is difficult at present, due to the presense of a
number of global variables and singletons, each of which must be reset
in order to achieve a purely fresh environment in which one can run the
test. If one or more of these are misssed, the test's behaviour may be
different to if it was run by itself. The isolation facilities of
nosetests have so far not proved reliable enough; so we have to
establish a clean environment outselves in the setup procedures.

This is the first step towards this; it removes the global web.auth
variable (and thus @web.auth decorators), and enforces a clearer control
flow on the setup of authentication information. Previously, it was
necessary to use the @web.auth.user_loader decorator to specify the
callback, call web.auth.config() to set up the client id and secret, and
it was only safe to actually begin using the web API once both those
steps had been done. And if you had multiple functions with the
@web.auth.user_loader annotation (as can happen in test cases), it would
be a case of "last one wins".

Now, the authentication configuration is done in a single, explicit
step, and involves creating an object which cannot possibly be in an
"unconfigured" state. The way to do this is as follows:

auth = Authenticator(client_id="<value>",
                     client_secret="<value>",
                     user_loader=my_loader_function)

This auth object can then be used to generate JWTs, and, more
importantly, used by the web.api.instrument method, which now takes the
authenticator object as an explicit parameter. This means that global
variable access for authentication is no longer enforced; you can do it
if you want to (as is currently still the case in hapi-flask), but for
tests you can have temporary Authenticator objects that last only for
the lifetime of the test execution, in the same way as you can create
temporary Flask application objects.

Additionally, the user loader function must now return a UserInfo
object, instead of a tuple. This contains the same information (user
name, account name, and roots), but is a bit more intuitive as these
fields must be accessed via name, rather than as elements of a tuple.
This makes code dealing with user info slightly easier to read.