Allow EXPOSED_HOST to be overridden in dev/no $BRANCH

Hardcoding this to 127.0.0.1 seemed to assume developing in an environment where the Docker host is localhost and the Kafka container is run with `-p 9092:9092`. This was a non-starter for boot2docker, Vagrant running a custom Docker host, etc.—it was impossible to connect a producer from the developer's host system, or even from another container on the same Docker host.

Now, using boot2docker, where by default container port forwards are exposed on 192.168.59.103, running:

    $ docker run -p 9092:9092 -e EXPOSED_HOST=192.168.59.103 relateiq/kafka

(plus a Zookeeper container) allows connecting producers or consumers either from the machine running the boot2docker VM or from other containers:

    # OS X boot2docker host with Kafka installed for use as a client
    $ kafka-console-producer.sh \
    >   --broker-list 192.168.59.103:9092 \
    >   --topic test

    $ kafka-console-consumer.sh \
    >   --zookeeper 192.168.59.103:2181 \
    >   --topic test --from-beginning

    # OS X boot2docker host using container as client
    $ docker run -i --rm relateiq/kafka \
    >   /kafka/bin/kafka-console-producer.sh \
    >     --broker-list 192.168.59.103:9092 \
    >     --topic test

    $ docker run --rm relateiq/kafka \
    >   /kafka/bin/kafka-console-consumer.sh \
    >     --zookeeper 192.168.59.103:2181 \
    >     --topic test --from-beginning

It should probably also be possible in the no `$BRANCH` mode to let `EXPOSED_HOST` fall back to `$IP`, possibly helpful if you're trying to model service discovery--like a CoreOS cluster--in development. But this is just a small first step (with a commit message far larger than the patch...).

The whole `$BRANCH` switch in `start.sh` is awkward for a generalized image shared publicly, but that's another matter, and perhaps not one RelateIQ is strongly concerned with fixing. ^_^