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.
Most of the views needs to be refactored eventually. Having all of this logic in the view is not an ideal design pattern. I think using decorators would be better. Also, a lot of the logic is to decide whether or not to show a particular section or label. I think that perhaps we should always show all sections/labels, and have a default value for when the content is empty. That way, the view logic is simplified, the markup is consistent across all detail pages, and visitors can more easily tell which parts are missing.

Here are some references for cleaning up views with decorators:
http://railscasts.com/episodes/286-draper
http://robots.thoughtbot.com/tidy-views-and-beyond-with-decorators