Modularize player creation DB call

#### What's this PR do?
It was pretty difficult to find material within the `.createGame()` function that was worth refactoring. And I'm honestly not sure if this PR is necessary, for reasons I'll talk about below. 

We previously had two sets of Mongoose code for the alpha-user and beta-user creation process. I pulled this out into a single function `createPlayer`, called in both cases. There are two things worth noticing here:

1. The function `createPlayer` takes a final argument, `extraCallback`, which allows the alpha creation function to send a response. This is necessary for alpha-solo game creation to work, as noted in the comments above this function call. 

2. The `logger.info` calls now log the same messages that the emitter emits. (I originally had the logger message strings inputted as an argument to `createPlayer`, but I thought this was unnecessary. Feel free to disagree--there's definitely utility in having consistent logging messages, and I don't want to change the messages halfway through our log files.) 

**Why do I feel like this is unnecessary?**
The `createPlayer` function saves maybe ~25 lines of code, but I think it might also make the code more confusing. Would it be simpler to just have the mongoose calls exposed, with the contents of their callbacks obvious?

#### How should this be manually tested?
I tested this with `npm test`, as well as using postman to make sure alpha-solo game creation and play still works. 

#### What are the relevant tickets?
Closes #320. 

#### Questions:
@jonuy--thoughts? Think this is necessary? (Definitely think finding ways to refactor `.createGame()` took way too much time. Trying to learn when it's not worth it!)
If that last parameter should be treated like a callback, wrapping the `self.response.sendStatus(201)` call up in an anonymous function seems like a more standard way to go.