Storyconfiginvalid

#### What's this PR do?
Our game sends a number of deliberately delayed messages to users, for instance at the end of levels or at the end of games. In its most essential function, this PR fixes a bug (see below) by checking, at the end of a delay period, to see if a user remains in her previous game before opting her into the end-game or end-level message. It does this by making a database call in the new `delayedOptinSingleUser()` function. 

Secondly, this PR divides an old function--`scheduleMobileCommonsOptin()`--into three different new functions: `optinGroup()`, `optinSingleUser()`, and `delayedOptinSingleUser()`. Unlike the first change, this change is non-essential. 

My reasoning in making this change? When we began thinking about how this function was to be implemented, we were thinking of solutions where **all** Mobile Commons optins were to be handled by a single function, whether 1) a single user was being opted into a new message, 2) a group of users were being opted into messages, or 3) whether there was a delay on the messages sent. 

Based on these three conditions, the "params" argument being supplied to the `scheduleMobileCommonsOptin()` function could vary, and the function itself could also accept an optional "delay" argument. I felt that this inconsistency was confusing, especially if someone had not taken a close look at the `mobilecommons.js` helper function file, and felt that separating the function into three purpose-built functions was clearer, and eliminated the need to construct "param" objects before the function calls. 

Finally, this PR changes all the `scheduleMobileCommonsOptin()` function calls to one of the three corresponding functions. 

#### Where should the reviewer start?
Start at the bottom of the `SGCompetitiveStoryController.js` file, where the three new function declarations have been written. Then check out where they're being called in the file. 

#### How should this be manually tested?
These modifications have been tested with the following scenarios: 
**Normal gameplay:**
  * Using Postman, created and started a two-player game with personal cell as alpha, dummy phone as beta. 
  * Played game through without inviting either player out of the game. Delayed messages worked as planned. 

**Inviting players out of games:**
  * Using Postman, created and started a two-player game ("game 1") with my personal cell as alpha, dummy phone as beta.  
  * Played game until the end of level 1, when I created a new game ("game 2") with different numbers, assigning game 1's alpha as a beta of game 2 and hence inviting me out of the game. Checked to see if I received any endgame messages. 

#### Any background context you want to provide?
Our app kept on throwing "story configuration invalid errors" caused by a user being invited to a new game (referred to as "game 2") while they were in the middle of a previous game ("game 1"). 

This error was thrown, specifically, when the user was invited to game 2 while she was waiting for a delayed message in game 1. (Delayed messages--usually messages about the outcome of the player's decisions within the group--come at the end of levels, or at the end of games.) The player would get a message asking them to text back 'Y' if they wanted to receive a message from their friend, then they'd automatically get opted into the delayed message. Since they were already invited out of game 1, their response to the delayed message wouldn't correspond to the right game on our backend, and since they were hit with the delayed message after the game 2 invite message, their response no longer registered for the invite message. 

Any texts from the user at that point on would hit our backend and be caught as an error, left unmatched with any active games, and we'd get hit with a "502: Story configuration invalid" error. 

Our solution is to check whether or not the user has been invited to a new game at the end of a scheduled delay interval. If the user is still in game 1, we send the message; if they've been invited out, we don't send any messages and allow them to text 'Y' to receive the message to join game 2. 

#### What are the relevant tickets?
#### Questions:
Towards the end of my tests, I started noticing two things: 
1. While using Postman, I noticed that it often took two POSTs for my user action requests to be displayed within the "story results" array in the gamedoc. (Though the first POST was always sufficient for the user to be opted into the next text.) 

2. Towards the end of my testing phase, my phone wasn't receiving the 'a user has sent you a message, text y' text when my phone was invited to a new game. Wasn't sure why this was happening, or whether or not MobileCommons flagged the excessive number of invites from the same number as spam.