feat: scoped data objects

[pkitazos]

This is pt.2 of the big backend refactor

Summary

• Introduce a new Scope abstraction that wraps the Prisma DB client and provides nice ergonomic, nestable transaction management
• I migrated the Project data object from DataObject (which uses the raw DB client) to ScopedDataObject, so it automatically participates in whatever transaction context it's given (it works similar to how the get operations for spaces on DOs either return a cached object or create one, cache it and then return it)
• the Project DO can now absorb standalone transactions
• the procedure never needs to drop to a raw db.$transaction (we can slowly start to phase db out of the tRPC context, in favour of the new sc (scope) which supports transaction when they are needed)

We are still not at the end of the road there is one or two more parts I would like to explore, but before I start committing to stuff, I'd like to get your feedback on this idea.

[JakeTrevor]

This is very cool work. I think it is a great step in the right direction.

There are a few minor points which are in the comments below - but there is one major point I want to raise right now.

I think the way scope.transaction works at the minute should be tweaked. There are details below, but the problem is that constructing a new scope object means that everything that uses the old one is unusable. This seems bad to me on a few levels.

Firstly, it means that we need to construct new DOs inside the tx. At the least, this is annoying. I think the fact that the objects are just there is part of what makes the proc api stuff so nice to work with.
But I also worry that it could error prone - you must not use the existing objects from the proc inside the tx, because they aren't using the right scope.

So I think the better solution is to instead have scope.transaction mutate the scope it's called on, so that the scope's db is the tx object. The advantage here is that so long as all the objects share the same scope (and they should) then calling transaction just makes everything work magically - so long as we can get it to work.

There's a sketch of what this could look like in the comments. It probably needs testing.

[JakeTrevor]

I don't have any major comments for this. I think the heart of it is very good. We can quibble about some of the tedious details later.