Return task IDs after emit, add Python logging and refactor IPC

When testing master against production topologies at Parse.ly, we found a number of issues which are addressed in this branch.  This branch is currently running against production topologies at Parse.ly with no issues (and passes all tests of course).  To summarize:

## Returning task IDs after emit

The emit method is supposed to return the task IDs the tuple was emitted to. Storm has actually always been sending us these, but we never called ``ipc.read_task_ids`` so ``ipc._pending_task_ids`` simply grew unbounded. So now:

* task IDs are now returned from ``Spout.emit`` and ``Bolt.emit`` but **not** ``BatchingBolt.emit`` due to inherit concurrency issues. ``BatchingBolt.emit`` instead now specifies ``need_task_ids = False`` in it's emit messages so that Storm doesn't attempt to send us any task IDs.
* I've deprecated ``emit_many`` as it causes similar difficulties with returning the task IDs an emit was sent to. We could go a different route here set ``need_task_ids=False`` with this method, but I think it's silly to have ``emit_many``.
* Tests have been updated to send fake ``task_ids`` after receiving emit commands from components

## Python logging

Debugging issues in our production topology was made difficult by the fact that we had no Python logging enabled. So now:

* Logging is enabled if users pass the option ``streamparse.log_path`` or ``streamparse.log.path`` when calling ``sparse run`` and ``sparse submit``. Ideally, we would pass these options for them, but I haven't gotten the quote magic working just yet.  **Would like some help to get that bit in**.
* Info on logging has been added to docs, it was super helpful in debugging our prod streamparse issues.
* If logging isn't configured, components will send a Storm log message warning users that this option should be enabled

## IPC refactor

* ``read_message_lines`` decided to be a bit too clever (generators, killing the trailing newline right after stdin.readline) so I've killed it in favour of ``ipc.read_message`` which features better docs and cleaner logic, IMHO
* In ``ipc.read_message`` Python 2 messages are decoded assuming ascii not utf-8 which caused UnicodeDecodingErrors
* In ``ipc.send_message``, when sending messages, stdout.flush wasn't called on sys.stdout.buffer, but instead sys.stdout
The use of `global` here has me wondering something I was going to ask before:  Do we need these `ipc` module functions, or could these just be methods in the `Component` class?