Refactoring 1) DB interactions, 2) Mongoose models, 3) consequent game logic code, 4) testing code

#### What's this PR do?
Quite a lot. 

1. DB INTERACTIONS - As noted in #315, we've rethought the way we connect to our database and use mongoose.model utility functions throughout the history of this app's development. In the "background context" section below, check out the differences between our previous usage of Mongoose, and our current usage.

(Note that we added the following lines to our `app/config/index.js` file, which prevents multiple connections being created during our tests--since we're loading a new express app each time we run a test.) 
```javascript
  // Only opens connection if its state is disconnected.
  if (mongoose.connection.readyState === 0) {
    mongoose.connect(app.get('database-uri'));
  }
```
2. MONGOOSE MODELS - Instead of our models returning the `app.getModel()` function call, we now have a more streamlined way of both expressing the components of the model, as well as how we're referencing them. (Instead of attaching the getter and setter model functions to the `app` variable, we're now just requiring the model files at the top of each file which uses them.) 

3. GAME LOGIC CODE - we went through all of the game logic controllers and routers, and made sure that 1) all the files now use the Mongoose models as described above, and 2) that they no longer pass in the `app` variable into functions, since `app` is now global. (This accounts for 80% of the changed files below.) 

4. TESTING - those changes we made to the game logic controllers? We also made to the test files. Additionally, we also 1) modularized some more of the test files, including a new function in `testHelperFunctions.js`, and 2) removed all reliance on the old `test-competitive-stories.json` file by a) deleting that file, and modifying `GameAlphaStart.js` to use BullyText for testing, and b) by deleting `GameAutoStart.js`, since all other testing files also test auto start functionality. Our automated testing process is now a lot more concise without sacrificing coverage, and we've removed roughly ~150 tests. 

#### Where should the reviewer start?
The content of this PR is very long. I'd first check out the `app/config/index.js` file has changed, to see how we've changed our interactions with the database. Then, I'd check out a few of the models in `app/models`. The rest of the changes are more trivial to future development. 

#### How should this be manually tested?
I've tested all of the responder functionality manually with Postman (testing different modules or libraries of functionality, such as Tips, PregnancyText, SGCompetitiveStoryGames, etc.) 

I've also tested with `npm test.` 

#### Any background context you want to provide?
**How did the previous Mongoose usage in the app work?**
1. We created a connection to the database in app/config/index.js, with Mongoose. 
2. We use mongoose.createConnection(database-uri) in this file
3. createConnection returns a created Connection object. Each connection instance maps to a single database. (We might want to create multiple connections when managing connections to multiple databases.) 
4. this reference then gets passed, on the behalf of a function attached to app ([app.getModel](http://mongoosejs.com/docs/api.html#connection_Connection)) 
5. app.getModel finds a model name, and then returns the connection with a defined or retrieved model to wherever in the app we’re looking for it. 
**How do we want the current Mongoose usage in the app to work?**
1. We create a single connection with a single mongoose instance and then create models off the single mongoose instance. 

#### What are the relevant tickets?
Closes #315. 

#### Questions:
Should we remove the following pending tests in `testHelperFunctions.js`? Since the betaJoinGameTest function is used for both the first beta joining the game, as well as the beta who auto-starts the game, it's difficult to check if the appropriate MC optins are sent given that the volume of messages triggered, and the opt in path of those messages, are different. 
Not something for this pull request, but something that would be good for us to do is define, in the constructor, the properties that this object uses. Like `this.storyId`, we could set to undefined or null or something here. It both serves as a way of knowing what properties are available and providing a defined state for that property when it's not set.

Do you know off hand if there are more properties than just `storyId`?