Yet Another From Idea, Destroy the Writer

We can write `innerJoin` relatively easily:

```haskell
innerJoin :: forall t. PersistEntity t => (SqlExpr (Entity t) -> SqlExpr Bool) -> SqlQuery (SqlExpr (Entity t))
innerJoin k = do
t <- from $ table @t
where_ $ k t
pure t
```

Well, okay, it's a `CROSS JOIN` with a `WHERE`. Usage looks nice.

```haskell
q = do
a <- from $ table @A
b <- innerJoin @B $ \b -> a ^. #id ==. b ^. #a
c <- innerJoin @C $ \c -> a ^. #id ==. c ^. #a
d <- innerJoin @D $ \d -> a ^. #id ==. d ^. #a
...
```

With a bigass query, and lots of tables, the `on` lambda becomes a bit cumbersome. Factoring this out helps a lot.

But...

Well, it's a hack - it only works because `FROM a, b WHERE a.id = b.a` is equivalent to `FROM a INNER JOIN b ON a.id = b.a`. We can't do left joins, and it also re-opens the problem for `LATERAL` if we allow subqueries.

If we had access to the `[FromClause]` in the `SideData` record, we could easily do this.

```haskell
innerJoin k = do
c <- getFinalClause
(_ :& t) <- from $ c `InnerJoin` table @t
`on` \(_ :& t) -> k t
pure t
```

except, well, we'd need to *overwrite* the final clause.

Even *getting* the final clause isn't possible with `WriterT`. It's fine with `StateT`.

Except, well, fuck, all the `Experimental` stuff is doing `FromRaw` and building the bytestrings directly. So modifying them after the fact isn't really a thing.

Actually maybe it's fine. Anyway I need to explore this a bit more.

Start with the Experimental code paths using FromRaw, then inspect how SideData and WriterT handle the final FromClause. Compare this with the StateT behavior described in the issue and trace how generated bytestrings constrain later changes. Done means establishing a viable direction for joins that also accounts for left joins and LATERAL subqueries.

Written by the indexing model from the issue text.