Rate-Limited Tokens: enable time-based policy windows

[tlepoint]

Section 5.1.2 and Section 2 state that

The effective policy window for a specific Client starts when the Client first sends a request associated with an Issuer.

and is defined in seconds. This makes challenging to create policies of the form “one token per client per UTC day”, which seems quite natural (e.g., this seems to be the policy adopted by Wordle-like games :-)). For example, a newspaper may want to allow 5 articles per UTC day, instead of 5 articles every 24h.

Would there be a way to be less restrictive / more generic in the definition of the policy window?

[chris-wood]

Building on #179, we can address this by adding a parameter to the RateLimit-Limit header which specifies that the window starts on an edge determined by the Issuer, rather than Client activitiy.

Long overdue, but the RateLimit-Limit header doesn't seem right here since it's meant for something else.

[tfpauly]

Next to issuer-policy-window, we could define a property like issuer-policy-window-start, which would include a UTC timestamp for when the policy windows all begin and must align to.