implications table

[michielbdejong]

From the thinking of #147 -
Create a new table implications that links movements and statements together.
Drop the type_ from movements and add unit there.
The statements table has lots of columns that came from the sync table and need cleanup

[michielbdejong]

We can separate out the switch to statements/implications/movements and do it only for finance first, and for timesheets later.

It also involves a decision about how to deal with log replay functionality.

PreJournal is both a tool for flexible bookkeeping from source documents,
and a tool for running a node in a federated data network.

This means it's probably useful to have a DSL (like .pj) that can be replayed.

But the statements table is also this replayable layer.

Maybe the code should be structured such that the db contents can't be changed without going through the bottleneck of statements.

Maybe the movements table needs a tombstone column to do this properly.

[michielbdejong]

CLI, API client, API server all produce statements and queries.

These go to the DAO statements are logged, and through implications, movements (tombstoned or not) are created / updated.

There is only one truth of movements in one PreJournal instance, but various statements can imply various movements, so that still gives a multi-faceted view of who says what, and allows for e.g. disputed transactions.

It should be possible to merge movements (just create a new merged movements, rehang the implications to it, and then tombstone the old ones)