Add a page to see our current Twitter API consumption state

[keithamoss]

This is required if we can't get an increased rate limit per #21. Refer to #6.

Just a visual at this stage. Call the API directly.

Actually, given the rate limit endpoint itself is rate limited we might want to cache it locally too. Then we can make use of it in stuff like threading where we want to start backing off or changing behaviour based on our API usage. Think about what our fallback position is for "we've been rate limited in this 15 minute period and the queue of tweets to process is building up" (e.g. In that "mode" we can assign sub-tweets to people as individual tweets that have no thread relationship).

Actually, we should be refreshing and logging our rate limits pretty frequently so we can do post-election analysis of how close we came. This would be paired with logging from the functions that use the API to give us a clear picture of how we're using the API and help inform future enhancements/changes in application behaviour.

Future enhancements:

• Logging this data at frequent intervals to see how close we ride to the edge.
• Using this data to queue up and execute replies/favourites/retweets rather than executing them directly. This would let us, for example, prioritise certain actions (e.g. replies) over others if we're close to the rate limit.

[keithamoss]

Done now