Discussion on irc has brought us back to the idea of starting with the api
outlined in msg78, but with some changes.  First of all, there does need
to be a global list of profiles, because there is a demand for being able
to enable, disable, and switch profiles via interactive commands.

The procedures to define and undefine profiles should be called
define_proxy_profile and undefine_proxy_profile in order to be consistent
with existing conventions.  Note that the `undefine' procedure is probably
not necessary, but we might as well have it for api completeness, given
that it is trivial to write.

PROXY_NONE is not useless, as it says in msg82.. or at least it is the
case that poeple will want to be able to interactively disable their
proxy.

Last is the question of the exact call form of define_proxy_profile.  In
my view, the best would be:

   function define_proxy_profile (name, obj) {}


  ..where OBJ is an ordinary javascript object possibly containing a field
for each of the Mozilla proxy prefs.  This object can be used directly as
the profile value stored in the global list.  If for whatever reason we
need to add properties, methods, or accesssors to it, that can be done
concisely by setting its __proto__.  Though I happily defend the use of
keywords as syntactic sugar in many cases, here I don't think they are the
right tool for the job, as they impart no benefit, and a simple javascript
object is the obvious, simplest implementation.  Additionally:

 * The keywords syntactic sugar is best suited to conveying "extra"
   information to a procedure or constructor, but in the case of
   define_proxy_profile, all of the fields are "main" information.

 * By convention, `define*' procedures that assign a value to something
   have a form like:

     define_thing(name, value);

   This has a more obvious meaning than the form:

     define_thing(name, $option, $option, $option);