add ratelimiting decorator

[RensDimmendaal]

This PR depends on: #867

This PR adds a token-bucket rate limiter for FastHTML routes. I figured we needed something like this for the MagicKey PR to avoid abuse of the routes that send emails and I saw it was a common pattern for other web app frameworks. What's different about this implementation is that I've made it easy to re-use the request parameters as a key in the limiter.

I didn't add a separate explainer doc page, because the source doc page is quite extensive and builds up nicely. But i can add one if you like.

Example usage:

 from fasthtml.common import *
 from fasthtml.ratelimit import limiter

 app, rt = fast_app()

 @rt(before=limiter('5/m'))
 def index(): return 'ok'

 @rt(before=limiter('100/h',key='user_id'))
 def api(user_id: str): return 'data'

Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist
Go over all the following points, and put an x in all the boxes that apply:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I am aware that this is an nbdev project, and I have edited, cleaned, and synced the source notebooks instead of editing .py or .md files directly.

Additional Information

The changes to nbs 00 and 01 are due to the latest nbdev-version and not related to this PR.

[RensDimmendaal]

@jph00 I wasnt sure how to best handle the default key-ing on IP, because dependent on the reverse proxy, cloudflare and uvicorn setup.

I've made it such that it'll work for local dev and for our common deployment scenario of serving with uvicorn behind Caddy.

I've added this note in the docs, and clarified when client_ip should (not) be used.

But I'm a bit unsure if this is the way to go...maybe it's too opinionated and we shouldnt make client_ip the default?