Make attribute presence checks more flexible

Using the `key?` method, as in `org.key?(:attribute)`, to check for the presence of an attribute assumes that the API will never return attributes whose values are nil or blank. By checking for the presence via `.present?`, it allows the client to continue working even if the API decides to return nil/blank attributes. The next updates to the API will in fact return nil attributes, so this change is necessary to make sure this client still works once the updates are pushed.

This change works with the current version of the API, so it can safely be merged even before the API updates are pushed.

In the process, I also cleaned up a bunch of unnecessary presence checks, and optimized the code.

UI changes include:

- On the details page, always show both Physical and Mailing Addresses, and show Physical Address first. By not showing one or the other (as we had before when they were the same), it made it look like that the one that wasn't showing up didn't exist.

- On the results page, only the first phone number is displayed. Otherwise, you'd end up with a bunch of phone numbers without any context for each one.

I also spent a lot of time that I hadn't anticipated fixing the filter specs which started breaking again for some reason. I switched back to capybara-webkit because Poltergeist wasn't able to click on the toggles. Instead of using CSS classes, I tried using the xpath, and Capybara said that it couldn't click on a particular element because there was another one overlapping it. I think this is the main reason we have been having so much trouble with these specs. I'm not sure whether or not having overlapping elements is considered a bad practice, but it certainly doesn't help with these tests. I think I was able to find the right xpath to click on, and so far, the specs are passing locally.

I really can't wait until we replace the filters with just one simple input field for location and agency name.

I also fixed issue #462 because I wasn't sure whether the filter specs issues were due to RequireJS not being loaded.
I kind of preferred having the section titles ("Languages Spoken" and "Accessibility Options") here in _body.html.haml so that the hardcoded text for section content was visible in _body.html.haml and the partials just extracted out the clutter of the HTML structure. What do you think about this? Are we sure we want that text content buried in the partial itself?