Editor Mapper

[RobertBColton]

This pull request introduces a new class which encapsulates the hierarchical data binding of the editors. It abstracts knowledge of how the message models are structured behind an interface that only requires knowledge of the protocol buffer's structure. Things like mapping of master detail interfaces, such as the Room View combobox, is automated by the interface (e.g, pushView). What this would allow us to do is change the model structure later on and not have to recode every editor. It would also allow us to flatten the existing models to solve #127 without having to recode all the editors because the mapper would be responsible for mapping the fields number into the flattened field index.

• All editors now have only a single _mapper member which is the new mapper class.
• All editors now use the mapName/pushAsset/mapField idioms of the new mapper.
• The timeline editor is an interesting case of master detail in that it's not using pushView interface yet. Fundies made code editor a stack of code widgets, which is kind of necessary for them to maintain separate undo stacks. I'm not sure what to do about that as I had never considered hitting undo in a detail widget of a master detail interface. One issue with fundies abstraction though is that CodeWidgetScintilla actually has that as part of its API and the documentation recommends that it be used in scenarios like this because it's more efficient as it will only maintain necessary things like separate undo stacks. https://www.scintilla.org/ScintillaDoc.html#MultipleViews
• The room views combo box now works using the new pushView interface. The view property widgets will now update as you hover over the list items in the combo's popup list model.
• The room will crash on a new room because there's no views allocated to the message. That's something we clearly need to fix. You can only test views combo by opening an existing room/loading a game for now.
• There's kind of a small issue with pushView in that it requires the submodel to be of horizontal orientation. We could fix that by making all of our models horizontal, even the flat one for properties, so that fields are always in columns. I think that would actually make more sense anyway.

[RobertBColton]

We don't know if we're going to do this yet because Josh would like all of this in the XML since it's boilerplate. I spent a little time investigating custom properties in the UI XML files again and had some success. The XML would handle the recursive bindings using a stack of mappers then, eliminating the need for this class. We could always do it with string names to map the widget by looking up the field number using the descriptor, but me and Josh both agreed that it would be better to fail at compile time if you misstype a proto field name. I managed to get enums working but there's a couple of issues in that it would require we include treenode.pb.h which already depends on every resource type and would slow down compilation.

  <property name="protoField" stdset="0">
   <set>buffers::TreeNode::kNameFieldNumber</set>
  </property>
...
 <includes>
    <include location="global" impldecl="in declaration">treenode.pb.h</include>
</includes>

I am wondering if we could hijack the MOC source files to handle this stuff so the treenode could be included in the source instead of the declaration. There's also the extension stuff that lets you do some cool stuff. https://doc.qt.io/qt-5/designer-creating-custom-widgets-extensions.html