Toolshed common-memory cleanup

[jakedahn]

This pull request teases apart some of the inter-mingling of concerns in toolshed and common-memory, to fix a bug found in sentry #316

When exposed in toolshed, the common-memory code runs into issues with duplicate request body / json parsing.

To fix this bug, and to not run the entire http processing stack twice, I think we should move all of the http handling concerns for the /api/storage/memory endpoint up into the toolshed hono app; and update common-memory to expose non-http-handling functions for query, and patch.

Some background on the bug: The toolshed hono api has openapi request schema validation. The first thing that happens to a request is that it is parsed and validated. This happens to read the request body stream when running await request.json(), and then later inside our toolshed handler, we're passing that request object through to memory.patch(c.req)-- which in turn is running another await request.json(). This is problematic, because you can only read the request body stream once; so the common-memory code was crashing/erroring.

---

Some other things to consider:

• it's kind of weird that we're maintaining 2 http interfaces; one in common-memory, and one in toolshed, does it make sense to kill deno.ts in common-memory?
• still need to add tests

[Gozala]

I'm not sure layer between Request and Decoded request makes much sense, I'd say if we want to decode in Hono lets do there and just call transact / query, or we just give the full control to the service and let it do the parsing. This way responsibility of doing it kind of feels in between.

That said, I have no objections to just taking it this as is and figuring out clear layering in the future.