Improving and extending insert* transforms

[dylans]

In looking at some of the work on the recent code-block refactor, we determined a pair of use cases that might be useful for more general insert* transforms for various elements.

1. Within the insert* transform, exclude obviously bad behavior. For example, with code-block, don't support code-block elements within code-blocks
2. Give users an easy way within options to define rules for insertion. For example, with code-block, maybe a list of node types which are included or excluded as options in which a code-block could be inserted.

In general addressing these two scenarios could lead to less out of the box problems when getting started, and make it less likely that someone needs to override or extend built-in methods when they want to control how the editor structures documents.

[zbeyens]

I've PR changes to queryEditor to help in that direction: #538

Suggested options to insertNodes:

• at: standard option. Default is editor.selection.
• insertQuery?: QueryEditorOptions: if queryEditor(editor, {at, ...insertQuery}) is true, allow insert.
• exitQuery?: MatchOptions: Default insert location is editor.selection which is not always wanted. If defined and getBlockAbove(editor, {at, mode: 'highest', ...exitQuery}) is defined, insert to its next path. It means that we want to "exit these block types especially", works well with nested blocks. Single problem I oversee: getBlockAbove get the first match but we want the top level block to exit (e.g. for nested list, we want to exit the list root). So we need top-bottom instead of bottom-up check (mode option?).

Example for code block:

insertNodes(editor, { insertQuery: { exclude: [ELEMENT_CODE_BLOCK] }, { exitQuery: { match: { type: [ELEMENT_TABLE, ELEMENT_LIST] }}})