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
``ipc._pending_commands`` and ``ipc._pending_task_ids`` are not thread-safe variables nor is ``ipc.read_message``. In BatchingBolt, we have main thread repeatedly calling ``read_command`` and the _batcher calling ``read_task_ids``. Both of these need to block either until they read a ``dict``/``list`` or see a ``dict``/``list`` pop up in their ``_pending_*`` queue.

There is a solution to make it all thread safe, but it'll take some careful thinking. My naive approach at first was refactoring the methods to be something like the following, but I had deadlocks so I punted on it for now.

```python
def read_task_ids():
    while True:
        with _pending_task_ids_lock:
            if _pending_task_ids:
                return _pending_task_ids.popleft()

        with _message_reader_lock:
            msg = read_message()

        if isinstance(msg, dict):
            with _pending_task_ids_lock:
                _pending_task_ids.append(msg)
        else:
            return msg


def read_command():
    while True:
        with _pending_commands_lock:
            if _pending_commands:
                return _pending_commands.popleft()

        with _message_reader_lock:
            msg = read_message()

        if isinstance(msg, list):
            with _pending_task_ids_lock:
                _pending_task_ids.append(msg)
        else:
            return msg
```