Logging mechanism for Synnefo management commands

Design doc for the implementation of a logging mechanism for the
Synnefo's management commands.

Ref #3: Log all stdout/stderr for snf-manage invocations
Fix console output for management commands

From Django's documentation:
  When you are using management commands and wish to provide console
  output, you should write to self.stdout and self.stderr, instead of
  printing to stdout and stderr directly.

This patch fixes the managements commands to use the proper
stdout/stderr objects.

Ref #3: Log all stdout/stderr for snf-manage invocations
Use SynnefoCommand for django-admin commands

Instead of django's BaseCommand class, use out SynnefoCommand which
takes care of logging the command and its output.

Ref #3: Log all stdout/stderr for snf-manage invocations
Implement NewlineStreamHandler

When StreamHandler writes a formatted log message to its stream, it adds
a newline terminator. This behavior is inherited by FileHandler and the
other classes which derive from it (such as the rotating file handlers).

Starting with Python 3.2, the message terminator will be configurable.
This has been done by adding a terminator attribute to StreamHandler,
which when emitting an event now writes the formatted message to its
stream first, and then writes the terminator. If you don't want newline
termination for a handler, just set the handler instance's terminator
attribute to the empty string.

This class implements python's 3.2 StreamHandler.

Ref #3: Log all stdout/stderr for snf-manage invocations
snf-common: Add 'LOG_DIR' setting

'LOG_DIR' is the directory where log files are saved and is going to be
used to determine where to store the management commands' output.

Ref #3: Log all stdout/stderr for snf-manage invocations
Log Synnefo management commands to files

Create 'SynnefoOutputWrapper' which replaces Django's 'OutputWrapper'
and logs the command and its output in a file.

Ref #3: Log all stdout/stderr for snf-manage invocations
Update Changelog about commands logging mechanism

Add an entry to the Changelog about the 'Logging mechanism for Synnefo
management commands'.

Closes #3: Log all stdout/stderr for snf-manage invocations
Merge pull request #25 from iliastsi/feature-command-logger

All Synnefo's management commands are written as custom django-admin commands.
This means that every management command is in fact a class that extends
Django's BaseCommand class.

Django's BaseCommand provides the attributes self.stdout and
self.stderr and Django's documentation encourages the users to use these
attributes if they wish to write to the console. Django doesn't provide an
option to write the output to files and the user has to implement this
explicitly when implementing the handle method.

We would like to extend the above mechanism to allow every snf-manage
command to log all stdout and stderr output on a unique filename under a given
directory. The implementation should change nothing in the way that users write
management commands (only acceptable change is that the new commands may have
to inherit a new class and not the BaseCommand one). This means that
existing management commands should play out of the box and also that the
logging mechanism will globally apply to all of them.

Commands that do not alter the state of the server (i.e. *-list and *-show
commands) will be excluded from the logging mechanism.
cyclades: Change snf-dispatcher's default PID file

Rename snf-dispatcher's default PID file from 'snf_dispatcher.pid' to
'snf-dispatcher.pid'.
burnin: Fix 'project_id' param in 'create_floatingip'

Until now, burnin was using a 'feature' version of kamaki
where the 'create_floatingip' method had a 'project' parameter.
This parameter was renamed to 'project_id' for uniformity with the
other kamaki methods.

These changes have been merged to 'develop' branch of kamaki and the API
is not expected to be changed again. This patch changes the way burnin
invokes 'create_floatingip' to use the 'project_id' parameter instead of
the 'project' one.
docs: Add missing fields in project API
docs: Mention reassign action for networks and IPs
docs: Remove networks block from compute API guide

Networks API is already documented in a separate file.