MinionModel + resulting API changes

[direwolf420]

MinionModel has been made more expandable by incorporating a dictionary approach to the projectile data (from the triple of item/buff/projectile(s)), which currently only includes a Projectile.minionSlots override, but may have more info in the future.

The resulting API changes are as follows:

• "AddMinionInfo", int itemID, int buffID, int projectileID stays as is

• "AddMinionInfo", int itemID, int buffID, List<int> projectileIDs stays as is

• "AddMinionInfo", int itemID, int buffID, int projectileID, float slots becomes: "AddMinionInfo", int itemID, int buffID, Dictionary<string, object> projModel

• "AddMinionInfo", int itemID, int buffID, List<int> projectileIDs, List<float> slots becomes: "AddMinionInfo", int itemID, int buffID, List<Dictionary<string, object>> projData

This change makes it so there's always 3 parameters, two calls being for registering 1 projectile, and two for more than 1 projectile, with each variant allowing a simple definition that will assume default parameters for any additional data (such as "Slot"), and an advanced definition through a dictionary.

• "GetSupportedMinions" return type is the same, except the underlying data previously storing ProjectileIDs and Slots is now unified into a single object of type List<Dictionary<string, object>> indexed via "ProjData"

None of these changes are made to be backwards compatible due to mods adding summons having to recompile their mods anyways due to various tml changes.

Misc:

• SlotsFilledPerUse, which was unused on 1.4 as spider minions started using 1 slot instead of 0.75, is now fully removed because TML supports partial slots via StaffMinionSlotsRequired. Porting notes should remark this on the wiki
• Fix a bug where if a mod registers minions with different slots to 1 buff, itll always pick the smallest slot when displaying the count instead of only if the minion that has the smallest slot is actually summoned.