feat: add global kv-storage prototype

[backwardspy]

this change implements the beginnings of a generic kv-storage mechanism that allows us to simulate things like authentication flows.

#61 prototypes this from an auth perspective, and i have taken inspiration from that PR to create this implementation. in recognition of this i have co-authored this commit.

some of the differences from #61:

• i have not chosen a storage technology and instead opted for a simple global dict. this works fine for single node (and therefore local dev) setups, and lays the groundwork for what we need. i would like to make it easy to swap in any storage technology in future.
• i've gone with string:string k:v pairs to make as few assumptions about the use of this storage as possible. ideally it can be used in any case where performing one request changes the behaviour of a subsequent one.
• keys are not related to endpoints in any way, allowing any endpoint to affect any other. this could be dangerous in a larger multi-user setup, and i think it would be important to institute some kind of key naming conventions to ensure uniqueness. the advantage of removing this association is again flexibility.

---

example mocked auth setup

we have two endpoints, POST /auth and GET /secret

the POST /auth endpoint is configured with an action that sets authenticated=1 in storage

the GET /secret endpoint has two responses; a 401 default response and a 200 response with a rule of authenticated == 1

this enables the following series of requests:

GET /secret: <Response [401]>
POST /auth: <Response [200]>
GET /secret: <Response [200]>

running the same requests again within the 15 second expiry window gives a slightly different result where the first GET /secret succeeds:

GET /secret: <Response [200]>
POST /auth: <Response [200]>
GET /secret: <Response [200]>

waiting 15 seconds causes the authenticated key to expire and the result goes back to the first example again.

---

resolves #53