Allow paragraph.type to be extended (beyond checklists)

Following a conversation in Discord, the salient points of which I'll repeat here.

DW: We need to find a better way for checklists.

JGC: I'll repeat my suggestion to @Eduard that if he would happy to make the paragraph.type field accept other types, then we could do some experimentation in plugin land on checklists, and then see what seems to work well. Unless, of course, you have ideas sooner or later to try out in the Labs?
JGC: [we need] Developer-extensible types. I.e. you deal with the ones you know and treat any others just as text. The developer can then experiment with others. So it really only means you won't reject any other types that might get set. I've no idea what might come of it, but it opens the door for some wider experimentation, particularly if they could get picked up in themes as well.

EM: I know we discussed this one, something like * [waiting] Task?

JGC: For example, allow more than 9 paragraph types that the API specifies. I can then try setting some paragraph.types as 'checklist' or something, and the API will return that new type, so I can then do things with it. Or, as you say, like a 'waiting' type. With the HTMLView we have complete flexibility about what we could do with those, which again might make for quicker prototyping of ideas.

DW: I haven't thought a lot about this, but I like the idea of exensible types. Would allow for real "plug-in" functionality. Maybe down the road, we could have a JS template for all the commands that a type should respond to and let JS deal with it. So I could add a type "checklist", and when someone checks it, it sends onChecked or onUnchecked or whatever. In the mid-term, as @jgclark suggests, maybe you simply allow a paragraph to be any 'string' type. In the immediate-term, the idea of checklists comes up a lot, and I was thinking that having "checklist" types (e.g. "checked","unchecked") that behaves exactly like a task except doesn't get a @done and doesn't count as open tasks in the interface etc. would go a long way.

EM: I know what you mean with this use case, I sometimes create bullets and prepend a ✅ before the text. In fact, a checklist, which I don’t want to count towards open tasks. Maybe we should introduce this one as an official type. Like instead of a round box, have a square one and a little smaller or so?
EM: The only thing I’m missing is how should the custom types look like in the text? Its more challenging to introduce icons or something in the swift editor. It’s a different case though if we use the HTML as the preview and render things there

JGC: I suggest that you don't do anything about display -- yet -- but treat as 'text'. This is for us to prototype, particularly now we have the early stage of HTML views.

EM: Ok, thinking this further, types are at the moment detected by checking the markdown. For custom types to work we would have to add somehow a way to detect them. Means we need to define a pattern somewhere?