Add `auth` module

Nobody has claimed this yet.

The idea is still a bit rough but I wanted to make an issue for this so there can be some discussion. Auth is a pretty important utility and always kind of a pain to setup for an environment like workers. So I think an `auth` module would be helpful to worktop, and could work something like:

- Users
- A built in `UserActor` durable object, storing at minimum a user id (and as the d.o. key), but also being able to store any user data for an app like email / name / age etc.
- Authentication can be done through different "providers." We could do a `PasswordProvider`, where we handle a password and save it through hashing, etc. inside the `UserActor` durable object. Could do an `OauthProvider` and support a majority of oath providers. Could also do a `Web3Provider` and support validating signed messages from a crypto wallet like Phantom or Metamask. Specialized auth cases / providers ideally would be easy for worktop users to implement.
- Authorization is tougher, but something like [ABAC](https://www.okta.com/blog/2020/09/attribute-based-access-control-abac/) would be crazy cool to have as guards to routes. It's a lot bigger of a scope, but with this being on workers we could easily look at attributes like origin ip etc., while also using traditional roles / permissions on users. Minimally at least would be simple customizable route guards that have access to the user data (which would be grabbed from the session id in the cookie).
- Sessions
- Nowadays they're mostly done through JWTs, because traditional server side sessions are difficult to scale on normal db architecture. But the "stateful serverless" of durable objects mean that the ease and simplicity of server side sessions can make them a better pick over JWTs. Users can login, then we can simply send back a new session id in a cookie.
- Doing sessions this way also allow for more complex control of expiration, etc. There's some articles out there on this I read awhile back I can share, but I think d.o. enabled sessions can be a trifecta of scale, ease, and speed.
- Not sure how much data would be stored for the session itself, but I think they could just be in KV as a map from `session::sessionid` -> `userid`, then any more session specific data can be in the user d.o. itself

That's the core of my idea. Of course could also offer preset api routes for /login /logout etc., but Users and Sessions are the base of any auth. I can share some code too, I have simple working versions of these ideas, but they're tied up in the code of another proj. at the moment.

No files or tests are named. Start by reviewing the existing worktop architecture for Cloudflare Workers, Durable Objects, and KV, then assess the proposed UserActor, providers, sessions, and route guards separately. Done would require a decided scope and documented behavior for the selected authentication and session features.

Written by the indexing model from the issue text.