Parallel shard update

The live_upgrade script has been updated to using OTP code change hooks instead of killing off old processes to reload the code. The changes to the `logplex_shard` module include a state record change.  A `code_change` function head has been added to handle this case. The live_upgrade script uses `sys:change_code` to modify the state and resume the running `gen_server`. The `logplex_redis_writer` module is a simple server loop that already handles upgrading to the latest code version.  And `logplex_queue` does not require any state changes between versions.

Resolves a `bin/replace_shards` issue when shard is down caused by the `timer:sleep` call in the `logplex_redis_writer:init` callback.  Under normal conditions the `init` callback is called synchronously and `start_link` will not return until `init` returns. The `timer:sleep` call was causing the supervisor to lock for 1s waiting for the init to finish. This meant each time the downed shard writer (10 of them) failed, it would post-pone even the new shard writers from being setup.

In this case `proc_lib` is used, so it is possible to cheat and ack the init before even attempting to connect to redis. The supervisor is then able to process other child starts, while the writer process is still figuring out if it can even reach the redis instance.


This is something that I noticed when I was testing this change. I am unsure if it is a regression because of my earlier changes here or not though.

I will have a look around through the playbooks and see if there is mention of this. I have a feeling you are correct thought because of the hidden [`state_apply`](https://github.com/heroku/logplex/blob/parallel-shard-update/src/logplex_shard.erl#L203).