Changed save data in Questing Foe to allow for custom foe ids

[KABoissonneault]

After looking into this issue: https://forums.dfworkshop.net/viewtopic.php?t=6357

Normally, we can store any int value in a MobileTypes enum, which occurs when using custom enemies with ids not defined in the enum. This works as long as we don't rely on features that require a field to be defined, such as serialization to and from string.

I found that in fsSerializer, enum values are serialized as strings, based on the matching enum field name.

In the Foe.SaveData_v1 struct, we have foeType as a MobileTypes enum. This shows in the save like this

                    "resourceSpecific": {
                        "spawnCount": 3,
                        "foeType": "Knight",
                        ...
                    },

If a field is not defined for this value (ex: custom enemy ids), this gets saved as "foeType": null, which will default to 0 when loaded back in (hence the rat mentioned in the linked thread).

To work around this issue, I've used an int with the id value. I have considered using a string to retain legibility, but I was not sure if it would still work once people start localizing custom enemies (we only have the Career name to identify custom enemies, and that string is user facing).

With the new save data

                    "resourceSpecific": {
                        "spawnCount": 1,
                        "foeId": 277,
                        "humanoidGender": "Male",
                        "injuredTrigger": true,
                        "restrained": false,
                        "killCount": 1,
                        "displayName": "Morkuchas",
                        "typeName": "Ghoul",
                        "spellQueue": null,
                        "itemQueue": null,
                        "$version": "v2",
                        "$type": "DaggerfallWorkshop.Game.Questing.Foe+SaveData_v2"
                    },

I have found one other place where a MobileTypes is serialized, in ItemData_v1, with the field trappedSoulType. I have not provided a fix for this one, because:

1. many structs and interface use ItemData_v1 explicitly. Moving to ItemData_v2 would require updating all save structures using items to v2 (big change) and the interfaces (breaks mods)
2. custom monsters cannot be soul trapped as of now. we can keep this fix for later if we ever implement it

[KABoissonneault]

I had expected the [fsObject("v2", typeof(SaveData_v1))] attribute on the struct to cause fsSerializer to migrate the struct automatically. This is not the case. I suspect the migration only happens if Foe.SaveData_v2 was the top-level struct being deserialized. In the normal case of loading a save with a pending quest, the save data is nested as a generic object in ResourceSaveData_v1.resourceSpecific.

So, I do the migration manually here