STORM-495: KafkaSpout retries with exponential backoff

This is an implementation of the improvement request STORM-495:
    https://issues.apache.org/jira/browse/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.
Actually, in the spout I can't know how many times a topology is going to retry its messages, so at startup I can't know with certainty whether the retries might exceed TOPOLOGY_MESSAGE_TIMEOUT_SECS or not.  Plus there is the uncertainty of not knowing how long it will take to complete or fail on a given try.

I __can__ detect the problem inside fail().  Maybe I could add some kind of response there, like logging an error and just not retrying (since I know that this other retry will happen before the spout's retry would)?