Refactoring to make all fields object based

[KiameV]

Left remarks on Discord directly.

tldr -> I think you definitely succeeded in making the table access type safe. But I think we lose too many advantages of the original design to warrant this direction, especially since I think parts of it will over-complicate future development for the context of the mod.

Changes that are great

* config

* modifiers

* modernized enums, .ordinal

Not applicable

* Tables rewrite

* tables and models rewrite

Responded in discord but will summarize here: With this PR

• Parsers are no longer needed as the need to compile data can be done with a single line of code
• Adding type table structure will support future development, code maintainability, and remove duplicate/redundant code

[KiameV]

This last PR addresses some raised concerns and does one more sweep around code cleanup:

• Makes most classes static instead of having everything singletons
• Removed the Csv___ models as I found making fields private still works for parsing csv files
• Added more unit tests and fixed an issue with adding invalid monsters to the table (any monster without a Reward is omitted).
• Removed any business logic from the listeners, now just calls the StatsRandomizer service
• Renamed to StatsUtil to StatValueCompiler
• Broke the Index enums from tables and put it into models. Questionable whether this enum is even needed still.

[Ink230]

Going to close the PR. Feel free to make a new PR with the associated config, modifiers, and modern enum changes. Those are welcomed changes.

Blockers for the rest of the PR:

• The move to static classes from singletons pigeon holes us for future extension by limiting the use of interfaces
  • Of course not implemented yet, but why remove the option
  • Singleton pattern will let us move to proper DI if needed in the future with minimal revision
  • We lose polymorphic considerations by losing the singleton pattern
• The services/controller pattern being reworked to use bulky DTOs
  • The existing pattern is just simpler to use and contribute to
  • The Tables and their DTOs are bulky repeated implementations
  • This is not an advantage over the existing system
  • StatsRandomizer
  • The existing system attempted to keep a layer (as much as possible) between the LOD events and the business logic of the mod
  • The LOD mods may change in the future
  • The existing system provides some protection against this
  • The PR's implementation creates a high dependency on the current LOD mod API

Your effort is appreciated though and has demonstrated how one may go about typing csv tables. The advantages of this system however do not outweigh the disadvantages encountered. The mod's business logic is small now but is intended to grow greatly. The csv tables are intended to be fixed and only ever rise to 10-15 tables. Typing such tables should not impact so heavily the rest of the mod's current flow or design.