Refactor feature specs (work in progress)

This is a somewhat experimental refactoring that West Arete is doing for all of the high-level feature/integration specs for Scholarsphere. We're sending the pull request early so that everyone can provide their feedback. 

## Motivation & Goals

- Provide a consistent, bullet-proof way of setting up and tearing down application state, to keep each test isolated and prevent random false failures.
- Provide a clean, consistent, bullet-proof way of testing javascript-heavy and ajax-heavy pages and actions.
- Set up the poltergeist/phantomjs environment and encourage a testing style that prevents race conditions between the scenario setup, the headless browser, and the verifications.
- Modularize the rspec configuration so that concerns are independently maintainable and loadable.
- Develop a series of custom helpers to do common scenario setup tasks.
- Develop a series of custom rspec matchers to do common Scholarsphere-type verifications.
- Develop a consistent method for encapsulating CSS selectors, so that when the markup changes, the tests can be easily updated to reflect them. And for those cases where the selectors are complex, this complexity doesn't cloud the purpose of the test. 
- Develop a consistent style that helps future developers expand on the feature tests confidently.

We feel that we're currently making very solid progress on the majority of these, but there are a couple that have not begun yet (e.g. the custom rspec matchers). We're working our way through each spec, adding new ones, and we'll cover these as we see the opportunity.

## Implementation Notes

We're doing this incrementally in a separate directory (`spec.features`), so that we can make sure we're isolated from the current `spec/features` directory and environment. To run these specs, you'll need to specify the directory explicitly, e.g. `bundle exec rspec spec.features`. 

When we're getting close to completion, we'd like to bring this back into the current spec configuration, perhaps modularizing that test setup as well. We're very open to suggestion here.

We're working through translating the existing specs into the new style, and adding new specs to get fuller coverage. The more recent commits are going to be in a much rougher style (work in progress), and as we get them working, we'll refine the style. So if a feature spec looks rough, check to see if it's still undergoing refinement.

## Needs

Please post comments on this pull request with thoughts and questions on style, compatibility, reliability, etc. We're going out on a limb in some of these areas, and we'd love to know if there are things that we're doing that will be a hinderance or annoyance rather than a help.

Let us know if there are things that we can be doing to encourage or assist with reuse. If this is transferrable and desirable in sufia, we'd love to know if you can anticipate any obstacles that we might encounter, or if there's something that we could do (or stop doing) to make code reuse easier.

Thank you!
After things get merged, I'd like to see if we can easily do this with a little regexing. We'd definitely prefer to steer things towards the standards for the rest of the code.

Would all of you consider going so far as to disable the `#should` syntax for the project? 

http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax#configuration_options

Otherwise I fear that it's going to be hard for us to remember, after having so many years of  `should` under our fingertips…