Make the data-loading set of functions consistent

[meldckn]

The following functions are very similar, but currently not consistent. Make them consistent in names, behavior, and documentation so if someone knows one of them, they know them all, and they aren't confused by surprising behavior:

• loadSocialStructure()
• addCharacters()
• addRules()
• addActions()
• addHistory()

Tasks:

• Rename loadSocialStructure() to addSchema()? See also Resolve ensemble.calculateVolition[s] function name inconsistency #83
  • Also, would it be more consistent with the rest of the codebase to rename addCharacters() to addCast()?
• Make all or none cumulative:
  • addActions() and addRules() can be called multiple times and will add to, rather than overwrite, the saved internal data from previous calls. The rest are not cumulative and will overwrite their saved data.
  • (I vote all because they're called add_())
• Add data validation to all:
  • addActions() and addCharacters() don't do any validation, the others have some validation but plenty of error-checking TODOs and not consistent about how they structure their validation so idk. See also Make action validation #79
• Make return values consistent (and data transformations if possible, but that's a larger task)
  • loadSocialStructure() turns its given array of schema categories into a dictionary keyed by category name (the internal representation) and returns that
  • addCharacters() doesn't transform its data at all except to point to the value of the cast key and returns the value from getCharacters(), a user-friendly representation, rather than the internal one
  • addActions() also doesn't transform its data at all except to point to the value of "actions" key and returns it (the array of action objects)
  • addRules() returns an array of rule id strings (not objects, just ids)
  • addHistory() really doesn't transform its data (get exactly what's defined in the given data, an object, {history: array of history objects} rather than pointing to the value of that top history key, and returns it
• Name of class variable it saves to:
  • Each function saves data to a corresponding internal class variable for use in future ensemble function calls, but they're named super inconsistently. (This is more for Ensemble developer sanity, since users shouldn't ever see these.)
    • loadSocialStructure() --> socialStructure
    • addCharacters() --> savedChars
    • addActions() --> actions
    • addRules() --> ruleLibrary
    • addHistory() --> socialRecord
• Make the API function documentation (and jsdoc comments) consistent — Once the above behaviors have been made consistent, make a single template description and replace only the category of thing the function corresponds to (e.g., schema, actions, rules, etc). Easier to skim!