Investigate/implement strategy for Fast 5 of node/mark support

[Chris Fuller]

As seen for ADF Change 71 and 72, we don't have a good way to do Fast 5 rollouts of node nesting and permitted marks. I think we need to come up with something for this. My initial thinking here was:

• We have methods that indicate the supported content type for a node and what marks it supports. This is already the case, but their type signatures might need to be tweaked.
• As long as the type it returns is narrower than the declared type, it should be possible to return a different interface than the declared one for the class that restricts it to a subset of the nodes/marks of that type. The actual type returned can be restricted to a narrower type than what is declared for FF off and widened to the declared type for FF on.
• All consumers in the HTML, Wiki Markup, and Markdown transformers should be made to always use this actual Class instance that the method returns for their decisions instead of using the type declaration.
• All node/mark parsers need to have "unsupported" node/mark wrappers so that these will survive the toMap, parse, and copy operations without throwing exceptions.

Update: Unfortunately, that's harder to make work than it sounds, for several reasons:

1. Only the wiki markup transformer currently supports feature flagging anything.
2. That would be especially burdensome to introduce into the core library.
3. It is problematic to make the parse, toMap and copy behaviours depend on a feature flag state, because the output from these things can be persisted, and we never want to output something that we will not later be able to parse.

So rethinking this, I think it makes sense to handle the rollout behaviour in the transformers themselves. The core library can offer up information about what the old types were, but the transformers have to handle the heavy lifting themselves.

[Chris Fuller]

I investigated this and it's really hard to do without a really dramatic change to how the library works, such as moving the concept of a Context to the main library and passing it around everywhere, that would make it much harder to use.

Instead, the Rules are going to be as follows:

1. The main library will always try to follow the schema. It is up to consumers not to build content that the editor isn't ready for.
2. The wiki markup transformer has a context object. When new node nestings or mark applications need to be introduced, it will be up to the transformer to arrange for those features to be dealt with explicitly in its own code, whether by keeping the behaviour back-revved until the editor is ready or by feature-flagging that behaviour.
3. The markdown and html transformers will use the behaviour back-rev strategy only. For example, lists are currently being added to blockquotes. These transformers will check to ensure that only paragraphs are accepted even though the type system allows lists too. Once the editor changes are rolled out, those guards can be dropped in those transformers to take full advantage of the new features.