Added DataTreeConverter tests

[Earthmark]

Depends on #31

Added initial tests for the data tree.

Also added IEnumerable to DataTreeDictionary, this allows collection initializers on the object, making test cases easier to generate.

Before

var element = new DataTreeDictionary();

element.Add("Id", i);
element.Add("Name", "element-" + i);
element.Add("Position", new float3(i * 0.5f, i * 0.25f, i * 0.125f));
element.Add("Enabled", (i & 1) == 0);
element.Add("Weight", i * 1.5);

After

var element = new DataTreeDictionary
{
    { "Id", i },
    { "Name", "element-" + i },
    { "Position", new float3(i * 0.5f, i * 0.25f, i * 0.125f) },
    { "Enabled", (i & 1) == 0 },
    { "Weight", i * 1.5 }
}

Enumeration is for the keys on that level of the dictionary, EnumerateTree is for recursion.

[Earthmark]

As with #28 , once I hear back about what the test format is supposed to be, I'll update the test names to match the expected style. For now they're in the style of the local repo.

[Earthmark]

This was the test added to verify #33 , this is possibly not a useful test though. Some of the collections being enumerated are dictionaries.

If the order isn't important this can be changed to just ensure all items are in the enumeration, instead of caring about the order.

[Earthmark]

More tests around historic file parsing should be added in the future, a lot of the DataTreeConverter is repeated sections of file saving code, but it's difficult to simplify without historic edge cases.

[Frooxius]

We generally don't use uncompressed versions, so I think it's ok.

[Frooxius]

Hmm... is this something that can also be replicate with Resonite itself? Say you create ValueField and put MaxValue in it, save it and then it doesn't load correctly?

[Earthmark]

In resonite it appears to work correctly,

In my own testing though, if I turn that off the value that comes back as -1 (int64). I'm assuming some layer converting from the data tree to the component type does a reinterpert cast?

So at the data tree layer this looks suspect as heck, but higher up the type gets converted back so it's fine.

[Earthmark]

As per the discussion in #39, I'll see about swapping this to Verify to see if this is a bit easier to understand. That may express the long-double conversion more easily.

[Earthmark]

Turns out this gets messy, Verify doesn't include type names on the value fields, even if settings.AddExtraSettings(s => s.TypeNameHandling = TypeNameHandling.All|Auto) is used. It only includes type names on the object types.

For now I'll leave this as is then, I personally feel it's important to show the type-promotion, but I can shift it in either direction if poked.

Another test should be added at some point anyways to verify the Add methods all work.