STORM-495: KafkaSpout retries with exponential backoff

This is an implementation of the improvement request STORM-495.

The KafkaSpout keeps track of failed messages through multiple retries, and delays their resubmission to the topology with an exponentially increasing delay time.  The spout does not terminate the retry cycle (it is my conviction that it should not do so, because it cannot report context about the failure that happened to abort the reqeust), it only handles delaying the retries.  A bolt in the topology is still expected to eventually call ack() instead of fail() to stop the cycle.
I did notice this, but chose to leave it.  My understanding is that the topology is expected to eventually ack() all messages.  And if I understand right, if a worker JVM or host crashes, then the message will eventually timeout due to the topology.message.timeout.secs setting in backtype.storm.Config, and it will then be re-submitted to the topology and the new worker should ack() it at that point - since the new worker will still use the same kafka offset  for the key in my retryRecords map that the crashed worker was using.

I'm not 100% sure that covers everything, but as I have it, it's also working the same way cleanup of the _pending collection has been working and still is.  Also, I wonder if it is a good thing that there will be a visible problem if some topology is failing to ack its messages - in the form of running out of memory in this case.