Fixes #440 - upgrades to rails 4.1.1

- Updates rails gem to 4.1.1.
- Updates other gems to latest versions.
- Updates HumanServicesFinder to OhanaWebSearch (Fixes #408)
- Regenerates vcr cassettes.
- Removes deprecated treat_symbols_as_metadata_keys_with_true_values.
- Adds infer_spec_type_from_file_location to infer spec type.
- Adds new button parameter to link URL.
Upgrading RSpec should be done separately, please. There's an upgrade process that should be followed:
https://relishapp.com/rspec/docs/upgrade. Also, we shouldn't be using beta versions. The declaration should be `gem 'rspec-rails', '~> 3.0.0'`.

More generally, you don't need to update the Gemfile when you're just changing the patch version number. For example, if your declaration for a gem is `gem 'dalli', '~> 2.7.1'`, that means that you accept any version between 2.7.1 and 2.8 but not including 2.8. The proper way to upgrade a gem is to do it one by one, so that you can roll back if something went wrong. You should never upgrade more than one gem at the same time unless they depend on each other. In the example above, to upgrade dalli from 2.7.1 to 2.7.2, you don't change the Gemfile. You run `bundle update dalli` from the command line, which will upgrade the gem from 2.7.1 to the current 2.7.x version, which will then automatically set the correct new version in Gemfile.lock, and when someone pulls the latest code and runs `bundle install`, they will get the latest version. After upgrading each gem, you should run the tests to make sure everything still works. If the tests pass, then you can commit the new version. Does that make sense?

Also, not all gems need to have a version restriction. Rubocop, for example, should never affect our code, so it should be safe to always get the latest version.