Investigate rewriting the DOM to turn DotaObject types into thin wrappers around Key-Value trees

[RoyAwesome]

@Penguinwizzard mentioned doing this. Investigate it's viability and how much it would take to break them apart.

[RoyAwesome]

Possible option: Modify the DataClassGenerator to output properties that get/set from the Key-Value tree.

[Penguinwizzard]

The core idea behind this is that we should be able to have multiple views on a particular data set, for example, a unit, without having to care as much about syncing them up. KeyValues view, Object view, and so on can all just be interpreted as different interpretations of an underlying dataset. Instead of having them actually have different data sets, they should, as close to the actual interface as possible, share the data, so that updating one updates the others (in real time, if possible (and it's possible)). This also gives benefits later on; with the goals in some other issues of having better auto-suggest for various things, or automatic analysis of code, having a more readily workable data representation would be beneficial.

[AntonAderum]

This is a really good idea, definitely something we should do.

Also +1 for tossing in some lisp-styled comments @Penguinwizzard

[RoyAwesome]

So, as we discussed on IRC and some thinking on my part, the things that we need to look into:

• Making the Dota Object Model a light wrapper around a KV-Tree
• Having some kind of informed property modification for Dota Objects so that other editors can react to changes
• Having a way to serialize individual properties to text and insert them into the Text Editor when changed by other editors
• Integration with the new style and other currently non-working editors, like the AbilityActionCollection editor and the Link editor.