add `Decoration` object instead of re-using `Range`

Right now for value.decorations we’re re-using the Range objects, because they refer to two points with marks. But I think there is more we’ll want to do with decorations, and as currently architected any new properties that decorations support have to be added to Range which is awkward.

Instead, I think we should separate out decorations into their own Decoration model:

new Decoration({
  anchorKey,
  anchorOffset,
  focusKey,
  focusOffset,
  marks,
})

This would allow us to add a data property holding arbitrary end-user data. And a key property holding a unique identifier to identify the decorations across renders/updates.

[ianstormtaylor]

@zhujinxuan yup, we would introduce a renderDecoration prop for rendering them. The difference is that they are applied to ranges of the document without affecting the document’s data directly, versus marks which are applied to the text itself.

[jasonphillips]

• It would be good to be able to reference decorations easily, to be able to remove or update them as things change. The current implementation just has a value.decorations which isn’t keyed by anything, or typed in any way, so plugins can’t know which ones to remove/update if the state changes.
• It would be good to be able to associate arbitrary data with decorations. Right now technically this is possible via using range.marks, but it feels hacky.

These are issues I’ve had to work around recently (basically: updating a large set of decorations essentially requires dropping / rebuilding them since no consistent id exists; and we attach data to them but it ends up looking like decoration.marks[0].data everywhere, which isn’t pretty). So I think a new type of Object to handle these in a more focused way than Range+Mark sounds great.