with an event API. In addition to the LLEventPump name on which to listen,
LLEventAPI accepts a documentation string for event API introspection.
Give every LLEventDispatcher::add() overload a new documentation string
parameter for event API introspection.
Convert every existing event API to new conventions, introducing suitable
documentation strings for the API and each of its operations.

The bug was driven by the following sequence in llstartup.cpp:
            if(reason_response == "update"
                || reason_response == "optional")
            {
                // used to resend status event still containing "update",
                // erroneously instantiating a second forced-update
                // LLAlertDialog
                LLLoginInstance::getInstance()->disconnect();
                // quit with an LLAlertDialog still on sModalStack used
                // to result in LL_ERRS
                LLAppViewer::instance()->forceQuit();
            }
I hope to be able to introduce a test script to verify the fix. That
script would need to be able to call LLAppViewer::forceQuit() rather than
requestQuit(), which is already available via LLAppViewerListener.

At the same time, changed LLAppViewerListener to bind a functor to
retrieve an LLAppViewer instance (namely LLAppViewer::instance) rather
than an LLAppViewer*. Apparently the static instantiation of
LLAppViewerListener was calling LLAppViewer::instance() too early, before
things were ready, so the declaration was changed to pass NULL -- then
in each method, call LLAppViewer::instance() if the bound pointer is NULL.
Binding the LLAppViewer* is a Feathers tactic intended to avoid the need
to reference the singleton. Binding a functor still leaves it up to the
instantiating code to reference LLAppViewer::instance, while deferring
the actual call to that method.

methods. Introduce LLAppViewerListener based on LLDispatchListener,
instantiate a static one in llappviewer.cpp. Initial implementation only
supports ["op"] == "requestQuit".