Code generation for nested send nodes

[absolutedogy]

When we are reading the fields for an entity mapping, some fields will have shared names which at first pass looks confusing as an object can't have two "m_vecX" assigned to it.

However, this is because they are directly assigned nested values, which are determined by the send node for the item.

For example consider the following field on "CBodyComponentBaseAnimGraph"

{
    "Name": "m_vecX",
    "SendNode": "m_skeletonInstance.m_vecOrigin"
}

When we dump this field to the class definition JSON schema it will be represented as

"Fields": {
    "m_skeletonInstance": {
      "m_vecOrigin": {
        "m_cellX": {
          "Path": 0,
          "Type": "UInt16",
          "NetworkTyppe": "uint16"
        }
}

This also leads to a situation where we have multiple fields called "m_cellX" but they are actually being mapped to objects within the base object.

It might seem like this should be handled by a sub mapping, but the reality is that these are not sub entities but just objects within the base object that have direct mappings to them, so we are only given a single value in the field path assigning to them but need to look at the nested field.

As well this nested object will have to actually be generated as part of the class definition generation code.

So when parsing this entity it should produce a generated class that looks something like this.

public class CBodyComponentBaseAnimGraph{

    public m_skeletonInstanceDef m_skeletonInstance { get; set; } = new();


    public override UpdateProperty(ReadOnlySpan<byte> path, object value){
        switch(path[0]){
            case 0:
                m_skeletonInstance.m_vecOrigin.m_cellX = (short)value;
            break;
        }

    }
    public class m_skeletonInstanceDef{
        public m_vecOriginDef m_vecOrigin { get;set; } = new();

        public class m_vecOriginDef{
            public ushort m_cellX { get; set; }
        }
    }
}

Note that for this iteration of the project, because code gen is easy to make repeated code like sub classes without much effort, just having the send nodes treated as sub classes even if it might be a "shared" type is going to be the path forward.

In future iterations there should be some sort of context that gets kept during generation to track the creation of nested send nodes, but this is a more complicated task and there are other improvements to handle before that becomes a pressing issue.