Revert string types back to system strings

[monkeyman192]

A while ago I made some changes to simplify how strings are handled in the .cs files: 1425662
This had implications I didn't fully realise at the time, and since then there has been numerous issues around this change.
It has been suggested we revert back to the original mechanism.
I think this should be done, but with one caveat, we introduce the Alignment attribute for strings that need it so that we continue to not need to include explicit padding bytes.

Ie.

public NMSString0x20A field_name;

will get mapped to

[NMS(Size = 0x20, Alignment = 0x8)]
public string field_name;

And

public NMSString0x10 field_name;

will get mapped to

[NMS(Size = 0x10, Alignment = 0x8)]
public string field_name;

All others will be mapped like:

public NMSString0xXYZ field_name;

to

[NMS(Size = 0xXYZ)]
public string field_name;

This will have implications to anyone using the API as the method to get the value of the string will now no longer need the .Value() call on the field.

[monkeyman192]

Ok, so after some recent discussions I think it's time to revisit this issue. There are some good benefits to implementing this, and the tools which use the exml data could utilise a simpler structure.

One issue to be overcome will be the issue of arrays or lists of strings. We'll need to add an extra attribute to accomodate this so that we can specify the length of the array as well as the length of the string.
It has been proposed that we use Size to indicate the actual size of the object within the array/list (if required), and Length or Count to indicate the number of elements in the array (Count being a bit more explicit in it's meaning and difference I guess)

So previously when we have something like

[NMS(Size=0x15)]
public NMSString0x10[] fieldName;

It will become this

[NMS(Size=0x10, Count=0x15)]
public string[] fieldName;

Similarly, lists will change like so

public List<NMSString0x10> fieldName;

to

[NMS(Size=0x10)]
public List<string> fieldName;