Zotonic modules

This pull request is in line with my GSoC work on the Zotonic Module Repository Integration.

## Changes:
* Rename `zotonic-installmodule` to `zotonic-modules` since the script now does more than just install modules
* Add more module management methods (can be seen at the top of the script)
* Add test fixtures to test the module manager. This test fixture creates a site, and run some commands in there, and deletes the site when it is done.
* Perhaps the `coolest` change, is the ability to directly install from a given url. It currently works with Bitbucket(Mercurial), Github(Git) and GoogleCode(Mercurial) url specifications.
* Modules are installed in `priv/modules`, but can be installed in site specific directory with the `-s` switch

## Note:
* Currently, the module manager does not support module version/namespacing and dependencies. 
This is because, the Zotonic Module repository server does not return these as part of it's JSON data. I have made some minor changes to the ZMR, but to effectively handle module dependencies, we can do the following:
    * Ask module publishers to declare their module versions or dependencies when submitting a module
    * Allow module publishers to issue a command such as `bin/zotonic modules publish` in the root directory of their module. This `publish` subcommand will then extract the necessary information and submit them to ZMR. This extracted metadata will then be returned as part of the response from ZMR.
* The web admin module manager is hosted at https://github.com/mawuli-ypa/mod_zmm
* To run the tests, do `bin/zotonic` modules test. The only test that has been disabled for now is the module search since it requires some of the changes on my fork of `mod_zmr` - https://github.com/mawuli-ypa/mod_zmr/tree/gsoc2013. I will send a pull request to mod_zmr too.
* The script maintains the `optparse` argument parsing library instead of the `new` `argparse` library for several reasons:
    -  `Argparse` proved to be a bit opinionated and restrictive in how certain things such as subcommands and help   messages are handled. I could be wrong, as I don't have much Python programming experience, but `optparse` was more flexible albeit I had to write code for some of the things `argparse` `easily/freely` handles for you. 

## Known issues:
* There are currently 8 pep8 warnings. PEP8 is basically the Python coding convention guide. The warnings displayed  are all on lines that exceed 79 characters. These lines are `compromises` I had to make since breaking them unto new lines also `breaks` Python's indentation and some string related operations. I could be wrong here.
* On first call, the python script is a bit slow, but improves upon subsequent calls. I am not sure if this is from Python or the way I have written my code.
* Sometimes, `erl_call` fails with message: `erl_call: failed to connect to node zotonic001@localhost`. I am on Mac OSX 10.8.5, with Erlang R16B.  I am using the same environment variables exported by the `src/script/helpers/zotonic_setup` script
* Some modules still include `webmachine_resource.hrl`, and thus fail to build. 

I still think the code can be further refactored.

Thank You!


## screenshots of the web admin module manager
![screen shot 2013-10-08 at 01 45 52](https://f.cloud.github.com/assets/874863/1285930/b90fdd84-2fbb-11e3-9ced-6535b7344b1b.png)
![screen shot 2013-10-08 at 01 45 36](https://f.cloud.github.com/assets/874863/1285929/b90b13c6-2fbb-11e3-8949-b810bf63647f.png)