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. 
The `withPhone` and `withUserInput` feels overly verbose as opposed to just `phone()` and `userInput()`. But then I also like the `expect` prefixing `NextLevel*` methods. So, I'm torn. [Builder Pattern](http://www.javaworld.com/article/2074938/core-java/too-many-parameters-in-java-methods-part-3-builder-pattern.html).