save(): available in request and response rule sets

new user preferences (save):
============================
* boolean: enable request persistence
* string: path to output file
* integer: upper limit of # requests that can be saved

new user preferences (replay, not yet implemented):
===================================================
* string: path to download directory
* string: path to 'wget'
* string: 'wget' options

the use case:
=============
* a rule contains a function
* the function inspects attributes of either
  the request or response, and conditionally
  determines that this is a request
  that should be remembered.
* the function calls: `save()`
* a serialized JSON object is PREPENDED to:
  `output file`
* if the number of lines/objects in `output file`
  exceeds its `upper limit`, then truncate the LAST line

the value:
==========
* there's some value in merely being able to save
  all of the details pertaining to "interesting" requests
* the REAL value (imho) is to implement the ability
  to "replay" any of these saved requests
* I tend to use 'wget' on the command line,
  so the first tool that will be supported is 'wget'
* I plan to design the api in such a way that other tools
  can easily be added later (ex: curl)
* I'm still debating on the best UI..
  the simplest way to visually present to a user
  a list of the saved requests, and the ability to
  easily select one to "replay" the original request.
* but truthfully, that's the easy part..
  the harder work was to save the data,
  and that's done and working really very well.
pondering an idea for how a user may access the saved requests

the file:
    ./[2. replay UI options]/01. silently injecting rules into request data set/base_request.js

..contains the fundamentals for an idea that I had

* we're defining our own URL protocol,
  and adding rules that will intercept requests made to this protocol,
  which allows the desciption of what looks similar to a REST-ful interface.

* URLs to this protocol are matched against a series of rules.
  a matching rule will extract information from the URL path.
  this information is then used to call an appropriate function handler,
  as well as the data that should be passed to the handler.
work in progress..

* most of the "replay" infrastructure is built
* none of it is tested

I actually just tried to run a 1st test, loading the URI:
  moz-rewrite:/print/wget

..but FF threw a "the address wasn't understood" error message.
..this happens BEFORE the addon even gets the opportunity to intercept the request.
..shame, seemed like a clever idea

anyway, all of the library functions are high-level.
this set-back doesn't dimish their value.
I just need to rethink exactly how the user is going to get to the point
where they can view the saved data, and trigger "replay" requests.
wget is implemented and working

done:
=====
* refactored a bit of pre-existing code
* added classes to support "replay" inheritance,
  including the first non-abstract class,
  which implements the interface using 'wget'
* reorganized the 'preferences' dialog using tabs
* some (basic) testing:
  - pointed the 'wget' executable to a mock utility,
    that simply echoes it's command-line arguments
    to an output file.. for inspection.
    * all of the argument values that contain characters
      which would require that they be wrapped in quotation
      marks are properly quoted (by FF.. nice!)
  - pointed the 'wget' executable to a proper binary,
    ran a few sample downloads:
      * incomplete downloads are resumed
      * previously completed downloads are ignored (not clobbered)
      * all data from the original request is being included in replay:
        - headers
        - post: method and data
      * default 'wget' options are set to respect 'content-disposition'
        response headers.. so the filename saved is the same
        as the filename prompted by FF during initial download

to do:
======
  * next commit will add support for 'curl'.
    it may be helpful (later) to do this step in isolation,
    since the diff will show what is needed
    to implement any additional external download tool.
minor amount of code refactoring

in preparation for implementing 'curl',
I wanted to move as much code as possible (DRY)
into the "replay" base class.
minor amount of code clean up.. general housekeeping

* there was one bug:
  the code that was used to determine whether the checkboxes
  on the download dialog were checked or not.. always returned true;
  that's fixed.

* aside from that.. a few fixed typos