Refactoring and adding tests

#### What's this PR do?
Quite a few things: 
1. It moves out the test game JSON file from `competitive-stories.json` into `test-competitive-stories.json`. 
2. It refactors the existing Mocha testing files--`test/GameAlphaStart.js` and `test/GameAutoStart.js`--to use one instance of the game configuration object (referenced now from `test-competitive-stories.json`, instead of two instances. 
3. It completes all of the pending tests written before, except for those which actually test MobileCommons opt-ins. It does this with the help of `userAction()`, a helper function within `test/testHelperFunctions.js`. (This function has gone through a few revisions, and so it changes shape through commits.) 
4. It creates a new file, `test/testHelperFunctions.js`, which contains, well, exactly what it sounds like. 
5. It creates a new Science Sleuth game--`test/ScienceSleuth.js`with four players, and runs through it to the end. 

#### Where should the reviewer start?
It probably makes the most sense to review this lengthy PR by running through the six points above, and checking out those files in order. 

#### How should this be manually tested?
Running `npm test` from the command line. Also tested by deliberately breaking things, and running tests. 

#### What are the relevant tickets?
Closes #285, closes first two bullet points of #234. 

#### Questions / thoughts for the future:
Similar to the Science Sleuth end-to-end-each-player-chooses-A-for-everything testing, I'll write in BullyText testing in the future. 
I changed the SGCompetitiveStoryController logic so that it refers to the new `endgame_config` object when computing endgame logic. 

I've tested Science Sleuth gameplay locally (though I don't think that those tests would be more illustrative than the tests I've written) and all seems well. 

I'm going to give this some deeper thought now, though. This does seem risky.