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.
Yeah, that would be bad.

We could run through them all in the beginning, just to be sure (though we lose quite a bit of the speedup). If we still make the check, we could log a warning (or at least an info) if an unindexed event is registered after the _continueIndexing_ flag (which should probably be renamed in that case) has been set. If we see none like this for a few releases, it should be safe to enable the optimization.

A middle ground could also be to run through the rest of the current block, and keep the _continueIndexing_ warning. If there is any bugs or bad assumptions, there would still be a chance of losing events, but at least it would be quite a bit smaller, as it would have to hit in the boundary between blocks at for thing like off-by-one bugs to have an effect. If "last event first" doesn't hold in all cases, then all bets are of course off.

It's actually a liiiitle strange that they didn't implement "since" for events.