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.
I created a version of PartitionManager that stops retrying when it would run up against the TOPOLOGY_MESSAGE_TIMEOUT_SECS setting.  But while I was testing it, I discovered that the Storm framework is not actually failing the message after this timeout.  Did that behavior change recently?  I thought I remembered seeing it do that before.

Since it's not happening, the message ends up getting lost - neither failed nor acknowledged.  So maybe after printing the big nasty error message, I should still handle the message in some way - either ack() it or just let it keep retrying?