New requests_per_* API

[kstrauser]

This addresses #49. The current .per_second API is the inverse of governor's. There, it means "the number of requests to allow per second". Here, it means "the number of seconds between requests".

It would be bad to break the current API. Users who've written .per_second(10), meaning "about 6 per minute", should not find their server suddenly honoring "about 600 per minute". That would be bad. Instead, this creates a new API by deprecating the old methods and renaming them:

• .per_second -> .seconds_per_request
• .per_millisecond -> .milliseconds_per_request
• .per_nanosecond -> .nanoseconds_per_request

That means current code will still work exactly as before, but devs will be nudged to rename their calls. It also adds new methods:

• .requests_per_second (corresponding to governor's . per_second)
• .requests_per_minute (governor's .per_minute)
• .requests_per_hour (governor's .per_hour)

There's no .requests_per_{milli,nano}second because at that point the rates aren't actually being limited on hardware that exists today.

I think that .requests_per_second will be the most frequently used. That's what motivated me to file the bug and write this patch: I wanted to limit an API to 2 calls per second. When I wrote .per_second(2), I was surprised to find it meant 1 call every 2 seconds. I ended up with .per_millisecond(500), which to me sounded like "500 per millisecond". With the renamed API, that would be .milliseconds_per_request(500) which I find to be a lot clearer, or .requests_per_second(2) which is also clear to me.

[AaronErhardt]

Thanks, code looks good!