Update TODO

- somehow I forgot to extract the title of the Fcommand into metadata.
  I should totally do that.
- it's possible to bypass CSP if you intercept and modify requests.  Not
  sure that is something that should always be done, or if Fcommands should
  be able to request it.
Improve support for bg context

- add an example bg Fcommand that opens a new tab to Google.  Preload it at
  startup.
- invoke the bg code with a named arg so the author doesn't have to use
  arguments[0] everywhere.
- note that the same code path for running the bg code is used whether it
  occurs in response the Fcommand's page code calling onSuccess() or if it's
  bg-only code
- better support for bg-debug.  Drop into the debugger from within the bg
  code itself, rather than the wrapper so it's clear at first glance that
  the user is debugging their Fcommand bg code.
- wrap bg code execution in try-catch.  Log the error to console for now
  (better mechanism of presenting errors TBD).
Reference actual description data

- I'm now thinking it was a mistake to have some data in metadata and some
  on the root Fcommand object.  It would be easier to just put it all on the
  root object
Remove spurious + in error message
Move test fcommand preloading

- it doesn't belong in FactotumBg.js, since it has nothing to do with the
  module.  It does belong in background.js, since that does the actual setup
  and initialization of the extension
Test Fcommand cache can be global

- it doesn't need to live on the FactotumBg object, since it makes no sense
  to be there
Fcommand is now needed by bg code execution
Move method to Fcommand

- it's only used by Fcommands, so it's reasonable to have it live there
Be strict in tests
Notes about refactoring Fcommand data
Remove unneeded file

- for now, the stub help-handling code is fine