Incremental loading of Github events and issues.

This is an attempt to use the ETag header and since parameter to make the polling more effecient.

Sorry about all the stupid commits (updating README, then revert, commenting GPG, then uncommenting again), not entirely used to working in a fork. :)

The changes aren't super pretty, but I wanted to keep as close to the original design as possible, which may have streched it a bit too far. I'm thinking we could introduce some kind of indexer or fetcher class/interface that could be subclassed for special cases like Events to help keeping track of ETags and state, but I'd like your opinion first.

Fixes #15 when merged.
It has always been optional, AFAIK (the default was 3600 before).

I think we should let it stay, especially until we ETag everything. Without it, an unauthenticated user would be 100% sure to hit the request limit, and they might not care about the events at all, i.e. we don't for our project (we use it to do graphs for issue open time). But we should probably warn that it is a very real possibility.