Closes#1641
The `data/terrain.yaml` file is now the authoritative source of terrains, though `BlankT` is still a hard-coded special case.
I have not changed the underlying integer representation of terrain in the world function, which means that the `terrainIndexByName` Map in the `TerrainMap` record is needed for translating between `Int` and `TerrainType`.
# Demo
scripts/play.sh -i data/scenarios/Testing/1775-custom-terrain.yaml
# Changes
* There used to be a function called `integrateScenarioEntities` that combined the `EntityMap` stored in the `Scenario` record with the global entity map. However, the global entity map is accessible at parse time of the `Scenario`, so we do the combining there and only ever store the combined map in the `Scenario` record.
* JSON Schema for terrain
* Removed the distinction between "World" attributes and "Terrain" attributes
* Unit tests for scenario-defined terrain and related validations
* Validate existence of referenced terrain at scenario parse time
* Validate attributes referenced by terrains at parse time
Builds upon #1587.
Extract all symbol names that are not native to the current project and insert them into our own custom spell checking dictionary's "words" list.
The premise is that symbols that *are* native to our project should be spellchecked, but foreign symbols that constitute unrecognized dictionary words are presumably intentionally spelled that way.
# Convention
Manually-added words (i.e. for names in code that we've written for this project) will go into `.vscode/settings.json`.
The automatically generated word list from third-party packages goes into `cspell.json`.
# Usage
scripts/spellcheck/autopopulate-spellchecker.sh
The spellchecker in VS code can be quite noisy, given all of the esoteric terminology and shorthand variable names in code.
However, it is also super helpful for catching typos, if you can wade through the noise.
Adding a project-specific dictionary will significantly cut down on that noise.
This allows the validation to work in VS Code if one happens to open the symlinked version of a scenario file, which is easy to do accidentally via CTRL+P.
This saves a step in the development setup process.
Note that the settings file is included in the toplevel `.gitignore`, so any changes on top of this one will not result in a "dirty" repo.
