merge `change.value` & `change.meta` -> `change.payload`

[samuelstroschein]

Context

Lix has a first-level snapshot approach doesn't seem needed.

Similar insight as in https://github.com/opral/lix-sdk/issues/41: Lix is not responsible for applying changes. Hence, lix does not need to enforce snapshotting. A plugin can do "whatever" as long as plugin.applyChanges() updates a file as a user would expect.

For example, a csv format with no stable ids highly benefits (must have even) a patch based approach that can express:

1. change abc: row 1 has been deleted
2. change bca: cell at column 4 and row 1 has been updated to "username"
3. change bca depends on abc (else a "different" row 1 will be updated)

For file formats with stable ids, snapshotting on the other hand is fine. Applying changes from the last snapshot is good enough as a first version.

Proposal

Introduce change.payload as replacement for change.value and change.meta.

• let plugins safe whatever they seem suited to apply changes
• we can introduce change.snapshot later if we really need it or even better let a plugin dynamically return the snapshot from a given change plugin.snapshotOf(change)

Taking inlang as an example where snapshotting makes things simple, we could move the snapshot into the payload and have the same benefits:

payload = {
  id,
  snapshot, 
  ... other meta information
}

[samuelstroschein]

Commit https://github.com/opral/monorepo/commit/c2c2c53660ee197dfa45c7d05841553d0381ebd7 further strengthens the proposal.

I was not able to delete a change during plugin.applyChanges() if no parent exists (it's a create change). The information of the type id was lost given that no snapshot was saved.

We could introduce required id field in a diff reported by a plugin like diff.type_id but file formats with no ids like csv, markdown, html, etc. exist. To achieve generalizability, letting a plugin handle ids seems required.

[samuelstroschein]

I am confident about this change. If lix needs snapshots, we can introduce a plugin.getSnapshot(change) in the future.

[samuelstroschein]

Observations after writing LIXDK-153:

• Payload with a separate plugin.getSnapshot(change) API will easy optimizations in the future of, for example, only saving the properties of metadata that changes (storing deltas).
• Storing a snapshot as payload.snapshot and defining getSnapshot(change) => change.payload.snapshot seems to be the least risky way forward without hardcoding snapshots into lix.