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.
Merge pull request #466 from codeforamerica/api-updates

Make attribute presence checks more flexible
Update ohanakapa gem to version 1.1.1

This includes a security fix to redact the API Token from error logs.
Merge pull request #472 from codeforamerica/update-ohanakapa

Update ohanakapa gem to version 1.1.1
Fixes #365 - Edit UX for results map

In this branch, @millerEric made some UX changes to the results map
view in response to Issue #365 ("Google Map rollover is cropped out of
view some times."). @millerEric used infoBox.js from the Google
Maps utility library, because it allows for easy customizability,
including position and styling. Presently, the infoBox is displayed to
the right of markers to decrease the likelihood of it being cropped out
of the window. The infoBox can be styled either within its options
object, or by linking to a CSS stylesheet. @anselmbradford moved all
styles to CSS.

- @millerEric set the marker's optimized property to false in order to
prevent events from propagating through the infoBox onto the map (e.g.
to prevent markers underneath an open infoBox from registering a
mouseover event).

- @anselmbradford added a z-index for the close box [x] per
@millerEric original edit, because it was visible but not clickable.

- infoBox.js requires the google maps api to be fully loaded before
it is loaded. This has presented some difficulties because of the
asynchronous loading of the google maps api. @anselmbradford nested the
dependencies so they loaded in order, which consequentially required
the result-map-manager to become self-executing, for better or worse.

@anselmbradford's commit also edits the following:

- Removes the clearMarkers method, which is only needed if the map results
were updated via ajax (which isn’t currently used).

- Removes the metadata and summary text variables, which were no longer
used.

- Adds additional code comments to the map manager code.

- Configures infobox states using a bit mask so that complex interactions
can be programmed as toggleable flags that are then evaluated for to determine
when to open or close the infobox.

- Configures jshint task to allow bitwise operations that are needed for
a bitmask.

- Adds additional styles to the infobox to make it more consistent with
links and other such styling in other parts of the app.

- Adds CSS corner arrow to info box so it’s clearer which marker the info box
is pointing toward.
Fixes #338 - Adds two marker sizes.

- Built on the original work by @abourai in
https://github.com/codeforamerica/ohana-web-search/tree/338-map-icon-sizes,
adds two marker sizes and ability to swap between the two sizes when resizing
the map.
- Changes infobox to use a background gradient for corner instead of a
div.
Adds generic map markers

- Makes map markers generic.
- Sets info box corner color to the same as the markers.
- Removes marker title so that the browser’s default title shown on
hover doesn’t overlap the info box.
Fixes #473 - turns off poi markers

Google provides default markers for Points-Of-Interest, which are
clickable to show an info window. This commit hides these markers so
that the user doesn’t inadvertently click these markers.
Makes detail and result maps markers consistent

The detail view map marker was the default marker. This commit makes it
the same as the large marker shown on the search results map.
Fixes touch display map issue

Since touch displays don’t have mouseover events, this commit sets the
needed variables when tapping a marker as if it had been moused over
first.
Fixes #402 - Updates coordinates and map data

- Updates coordinates field to use latitude/longitude in places where
array bracket syntax was used to access these values.
- Updates cassettes to include latitude/longitude in response.
- Replace `generate_map_data` method with client-side JS code
- Define new @total_map_markers instance variable that can be used in
the views to determine whether or not to display a map, and for the
`format_map_summary` helper.

- Fix bug where the conditional for displaying
`@map_search_summary_html` was removed. See the bug in action here:
http://ohana-web-search-demo.herokuapp.com/organizations?utf8=%E2%9C%93&
keyword=test+location+with+no+street
Fixes #241 - add overlapping marker algorithm

- Adds https://github.com/jawj/OverlappingMarkerSpiderfier for handling
overlapping markers.
- Updates marker graphics and adds large/small spiderfied marker icons.
- Adds street address and city to info box.
- Moves info box close button to upper-left to aid in making the
opening/closing action of the info box closer together. Also, removes
corner gradient.
finished merge w/ upstream/master
Add setting to specify admin site URL. Closes #351
Merge pull request #477 from codeforamerica/link-to-admin-site-351

Add setting to specify admin site URL. Closes #351
Moves Google Maps plugins to be inline and Code Cleanup

The plugins work fine locally using nested require() calls. However, when
using the requirejs optimizer, the plugins were concatenated in the main
application script, whereas Google Maps API is loaded asynchronously. This
led to errors in production because the local concatenated plugins were
executing before their dependencies loaded. Having the plugins inline isn't
ideal, but based on research it appears to be the approach with the least
overhead and disruption of the existing site structure.

It allows:
- Guaranteed execution of the plugins after the Google Maps APIs have loaded.
- Exposure of the module initialization method to the outside. With a nested
require() call inside the module, the init method was not accessible outside
the module scope. As inline plugins the init method is accessible again and
can be used to specify where and when the module is initialized.
- Removal of vendor scripts and the associated path settings in the
requirejs.yml config file.

Alternatives to this setup that could be investigated in the future:
(a) The Promises based approach shown here
http://stackoverflow.com/questions/12648598/amd-version-of-google-maps-v3-for-use-with-require-js/
The consequences of this approach are the introduction of a jQuery dependency
for the loading and possible non-support for Promises in IE being an issue.

(b) Include directive. See
http://stackoverflow.com/questions/19337293/requirejs-optimiser-include-nested-dependencies-for-certain-files-and-folders
The plugins could still be nested like how they were set up and worked locally
and then explicitly included in the build. However, this may still cause them
to load before the maps, so that would need to be investigated on a staging
server.

Other cleanup and adjustments:

- Adds findNestedDependencies flag to requirejs config. Nested require
calls were not being included in the optimizer.

- Removes erroneous reference to term-popup-manager which is removed.

- Makes bitmask return boolean for isOn method, instead of actual bit
numerical value.

- General code cleanup and documentation added.
Disables filter specs

Filter specs are consistently failing on Travis. This disables them
till they are re-worked.
Simplify search filters

This replaces all the complicated view, JS, and controller code with 2
simple text fields for searching by location and agency name. This is a
familiar interface and keep things simple and maintainable. Anything
that would be built on top of this simple foundation should be based on
user feedback.

Note that the text fields are not styled in this commit.
Merge pull request #478 from codeforamerica/map-feature-update

Map feature update
Merge pull request #479 from codeforamerica/xit-filter-specs

Disables filter specs