res.cpp: Extract data into XML file

[OnlineCop]

While (still) poring over eResistance and other recent changes, I've found quite a few bugs (yay!). Having a giant wall of data in res.cpp isn't ideal, however.

If I were to move these into the data folder as an XML, it should have an added advantage of allowing the stats to be hot-reloaded via Lua, so we can test that things like spells and elemental attacks are doing what they're supposed to.

If anyone sees disadvantages/cons to this, let's discuss. Otherwise, I think I'll start this migration process.

[pedro-w]

Just as a reminder, in the JB days, all the data written as C code was in res.c, then we extracted it into the csv data files (in other/) to edit with a spreadsheet, and generated code from the data, then we went onto editing the code directly, now we're back to data. I agree being able to 'hot reload' would be an advantage.

On XML - will a giant wall of XML be easier to edit? (maybe there is a graphical XML editor out there, I don't know)
The only other alternative I can think of (short of adding in a dependency for a JSON parser) are to use Lua files as data (LSON, if you will) as Lua's literal object syntax is just as good as Javascript's.

[z9484]

I think lua might be nice as specialitems and items are already in global.lua just not their stats.

[OnlineCop]

I usually haven't done much Lua programming (it warps my brain), but I'm happy to move everything to Lua-based.

Pros:

• Data will already be in whatever format Lua expects, so it can ingest it very easily.
• Supports Separate KQ source code from the map editor into a different repo #10 (Separate KQ source code from the map editor) in separating the engine from the data.
• Supports Games as modules #20 (Games as modules) in further allowing game/story to be developed independent of the engine (like KQTheBetrayor).

Cons:

• Large refactor.
• Have to move the logic of how items work, both inside and outside of battle, to Lua as well.

If moved to a different data format (JSON, XML, csv, etc.) instead, we might still be able to write a Lua wrapper to ingest it, which should allow us to hot-reload the data (no recompile).