invocation, instead of just the first.

show(): added color keyword here so that the selected color can be
chosen on each invocation of askcolor().

Also fixed this class, and askcolor() so that the same Chooser
instance can be re-used instead of creating a new one on each
invocation of askcolor().

Added a module function save() which can be used to explicitly save
the option database in ~/.pynche.  This does not happen automatically
when used as a modal.

tkColorChooser.askcolor() interface (i.e. don't return a color name
even if there is an exact match).

run either as a standalone application (by running pynche or
pynche.pyw), or as a modal dialog inside another application.  This
can be done by importing pyColorChooser and running askcolor().  The
API for this is the same as the tkColorChooser.askcolor() API, namely:

    When `Okay' is hit, askcolor() returns ((r, g, b), "name").  When
    `Cancel' is hit, askcolor() returns (None, None).

Note the following differences:

    1. pyColorChooser.askcolor() takes an optional keyword `master'
       which if set tells Pynche to run as a modal dialog.  `master'
       is a Tkinter parent window.  Without the `master' keyword
       Pynche runs standalone.

    2. in pyColorChooser.askcolor() will return a Tk/X11 color name as
       "name" if there is an exact match, otherwise it will return a
       color spec, e.g. "#rrggbb".  tkColorChooser can't return a
       color name.

There are also some UI differences when running standalone vs. modal.
When modal, there is no "File" menu, but instead there are "Okay" and
"Cancel" buttons.

The implementation of all this is a bit of a hack, but it seems to
work moderately well.  I'm not guaranteeing the pyColorChooser.Chooser
class has the same semantics as the tkColorChooser.Chooser class.