Create common language for serialization types and marks

[klette]

I propose that we change the implementation to talk about type and mark serialization rather than MarkerDefinition and "custom serializer".

Perhaps we could find a common structure for these, as they all serialize/render into HTML.

Serializer
    -> TypeSerializer
         -> BlockSerializer
         -> ListSerializer
         -> ListItemSerializer
         -> ImageSerializer
         -> ....
    -> MarkerSerializer
        -> LinkSerializer
        -> StrongSerializer
        -> ....

That would match the upstream rendering pipelines somewhat more, although in a more OO-manner.

[sondrelg]

I had to do a quick refresher before starting #23, and thought it would be productive to quickly summarize my current understanding of the elements in the spec.

Types

The portable text spec indicates that there are only 2 primary types: block and span.

We have inferred a list type (because it's there), but it's not a recognized type as far as I can tell. There is also no listItem type, just a block with listItem specified (which is just one variation of block, right) - we definitely need extra serializers both of these here though.

From the upstream tests we have test 26 which uses the button type and several tests (e.g., 12) which uses the image type. As I understand it these are both custom types. This is extra confusing since the image type especially is so frequently used and is clearly built into sanity's own packages.

Mark definitions

A mark definition is something (anything?) referenced in a span's marks list. IIRC, the npm-package separates between
decorator and annotation mark definitions, which I'm not 100% clear on what the difference is, but we've mirrored the structure and now have the following lists

decorator marker definitions

• em
• strong
• code
• underline
• strike-through

annotation marker definitions

• link
• comment

Styles

In addition to mark definitions we have styles, which define the outer tags of the block - this makes more sense if you remember that blocks are meant to represent chunks of text, and that the Portable Text spec sort of assumes that this is how you break down your content.

We do not support any custom styles at the moment.