Create templating system

[nyxxxie]

Template files are C struct-like definitions of a target file's internal structure. Templates should be parsed and made accessable to users in such a way that they can be interacted with like a tree. An example of a template file would look similar to this:

struct struct1 {
    int32_t attribute1;
    int16_t attribute2; // this is a comment
};

struct struct2 {
    char data[32];
};

/* Entry point */
struct FILE {
    int blah;
    struct1 s1;
    struct2 s2;
};

The bare minimum implementation would parse a template file and allow it to be interacted with by the following means:

• Return Field associated with an offset into the file. Fields should also be capable of representing arrays in template files.
• Return Struct or Field associated with a string identifer (EG: template.get("FILE.header.signature") = Field object that marks the signature field in the header of the target file)
• Return entry point (FILE struct in template) of template and allow user to explore file in tree format.

The Field and Struct objects are defined as follows:

• Struct: Object that represents a struct in a template file. Should be able to return parent struct, fields/structs that are members of this struct, offset in file, and size.
• Field: Object that represents a variable (or data) in the target file. Should be able to return parent struct, type (this should be linked to typesystem, but can just return a string for now), and size. Additionally, it should provide some way to access info about the template array if it is defined as one.

Some features that'd be nice to have but aren't required for this issue (we can make them into seperate issues later):

• Ability to edit template (insert new struct instances of a given definition, define new structs, etc)
• Ability to store template in project database
• Ability to define array size as a member of a struct (EG: char member[size] or char member[FILE.header.size])
• Ability to "decompile" template back to a template file.

[nyxxxie]

Some future features to keep in mind when implementing this feature:

• enums

enum file_type {
    TYPE1 = 0,
    TYPE2,
    TYPE3
};

• in-place conditionals

...

file_type type;
if (type == file_type::TYPE1)
    char data[32];
else
    char data[128]; 

...

[nanokatze]

delet

enum {
    TYPE1 = 0,
    TYPE2,
    TYPE3
} file_type_t;

This

file_type_t type;
if (type == file_type::TYPE1)
    char data[32];
else
    char data[128];

should rather be close to C as possible, so

file_type_t type;
# if (type == file_type::TYPE1)
    char data[32];
# else
    char data[128];
# endif

would be better but i'm uncertain myself so keep this open.

[nyxxxie]

Deleted second enum declaration, as I agree it's just clutter. I don't want to use # for conditionals because that implies preprocessor, and the if statements that I describe would require live data to evaluate properly. We can hash the specifics of these out in their own issues when this one is complete.