Refactoring of DonorsChoose controller

#### What's this PR do?
In issue #267, our fearless leader @jonuy flagged a few errors logged by Winston. Though the errors were logged, they didn't provide too much information which would allow us to successfully debug. 

In this PR, we've done a few things: 

1) We've added more illustrative information to be logged with errors in Winston. Specifically, mobile phone numbers and full response bodies from the DonorsChoose API. 

2) We've pulled out the the `selectedProposal` parse logic from the try/catch block. Now that our code doesn't need to filter for a certain `costToComplete` property (since our API specifies this in the call), putting this code within the try/catch block is unnecessary. 

3) We've shortened line lengths. Many aren't quite under 80 chars, but we're getting there. 

#### Where should the reviewer start?
Start with the logic pulled out of the try/catch block (though nothing was changed in the logic.) Then check out the changes to the `logger.error` calls. 

#### How should this be manually tested?
Tested with postman, going through the donations flow. Created a few errors by removing variables and seeing what info was thrown. 

#### What are the relevant tickets?
Related to #263 and #267, but probably doesn't close them. 
This will work as is because the try/catch will catch both the `JSON.parse` error and also if `proposals` comes back empty.

But I wonder if we could be more explicit in handling of errors when we see them. Like, what we could do is...
```
var selectedProposal;
try {
  donorsChooseResponse = JSON.parse(data);
  if (!donorsChooseResponse.proposals || donorsChooseResponse.proposals.length == 0) {
    throw new Error('No proposals returned from Donors Choose');
  }
  else {
    selectedProposal = donorsChooseResponse.proposals[0];
  ...
```