Integrating the developer tools debugger

Hey Folks,

as you may know, I am working on integrating the Developer Tools 
Debugger into Thunderbird, so we can once again use a real debugger for 
development. The debugger server is packaged by Mozilla's Toolkit, so as 
long as its packaged, it will be possible to make use of it. The only 
thing missing is UI and a few actors to make sure a Firefox client can 
connect. More details on the initial implementation is here: 
http://kewisch.wordpress.com/2013/06/13/the-thunderbird-remote-debugger-is-alive/

One important thing to decide on is how to actually package the 
debugger. While the initial patches went into comm-central before the 
last merge, there are more (possibly better) options to consider to make 
sure that the debugger is available for all products. I'd love to hear 
some feedback from at least one person from each product.

*Option A: package extension as an extension within the app*
  - Here we would have a single directory in the build system that 
packages the debugger server glue as an extension
  - The extension would be installed and distributed with Thunderbird, 
similar to how Seamonkey packages Chatzilla et al.
  - The extension can be extracted from Thunderbird for uploading to AMO.
  -Downside: Thunderbird usually doesn't package extensions, TestPilot 
is going away too
- Upside: High visibility for developers, easier for others to 
contribute to the debugger if they are contributing to comm-central too.
*
**Option B: package files directly in app, extra extension directory *
- The extension files get installed into dist/bin, not in the extensions 
dir
- This way the extension is installed natively, without an addon-manager 
entry
- An extra directory exists in the build system to generate the same 
code as an extension, for uploading to AMO
- Upside: No extra entry in the addons manager
- Downside: No way to update the debugger glue without a full product update

*Option C1: package as an extension only*
  - The code would be removed from comm-central altogether, instead 
added to a repository on my github account
  - AMO uploads can be made periodically by zipping the source code as 
an xpi
  - Upside: No extra work for packaging, no maintenence in comm-* 
repositories
  - Upside: Not installed for anyone that doesn't use the debugger
  - Downside: Localization needs to be managed externally
  - Downside: Visibility is not very high. Would need to do some PR to 
make sure its known to developers
  - Downside: Yet another external repository for apps wanting to 
include the extension by default
*
**Option C2: package as an extension, download in client.py*
  - Like option C1, but instead host on github/mozilla-comm
  - Make client.py automatically check out the extension into 
mozilla/extensions
  - Add build system magic to allow building with the mozilla build system
  - Upside: More visibility than C1
  - Downside: Adds build system maintenance, also another external 
repository


Just an extra note, the overhead for the js debugger glue is very small, 
especially with the default of the debugger being off. I'm not going to 
say my preference now to get a most unbiased opinion, but I may chime in 
later on.

Looking forward to your feedback!
Philipp