Add docs for handlers, app handler

docs/narr/cli/commands.rst

@@ -110,8 +110,8 @@ are really aliases) or can use different functions:
        poser = poser.commands:poser_main
        wutta-poser = poser.commands:wutta_poser_main
 
-Next time your ``poser`` package is installed, the command will be
-available:
+Next time your ``poser`` :term:`package` is installed, the command
+will be available:
 
 .. code-block:: sh
 

docs/narr/cli/overview.rst

@@ -6,8 +6,8 @@ The command line interface is an important part of app automation and
 may be thought of in a couple ways:
 
 First there is the :term:`ad hoc script` which is a single file and
-can be placed anywhere, but is not installed as part of a package.
-See :doc:`scripts`.
+can be placed anywhere, but is not installed as part of a
+:term:`package`.  See :doc:`scripts`.
 
 But the "real" command line interface uses :term:`commands<command>`
 and :term:`subcommands<subcommand>`; these are installed as part of a

docs/narr/cli/scripts.rst

@@ -10,8 +10,8 @@ A script is just a text file with Python code.  To run it you
 generally must invoke the Python interpreter somehow and explicitly
 tell it the path to your script.
 
-Note that a script is (usually) not installed as part of a package.
-They can live anywhere.
+Note that a script is (usually) not installed as part of a
+:term:`package`.  They can live anywhere.
 
 Below we'll walk through creating a script.
 

docs/narr/cli/subcommands.rst

@@ -82,8 +82,8 @@ with underscore for sake of the subcommand entry point:
    wutta_poser.subcommands =
        hello = poser.commands:Hello
 
-Next time your ``poser`` package is installed, the subcommand will be
-available, so you can e.g.:
+Next time your ``poser`` :term:`package` is installed, the subcommand
+will be available, so you can e.g.:
 
 .. code-block:: sh