Remove RSpec guideline for one-liners

Previously one-liners could be written in RSpec like:

    it { should validate_presence_of(:name) }

In RSpec 3, the `should` syntax was removed because it monkey-patched `Object`.
The one-liner syntax shown above was kept because its `should` did not
monkey-patch `Object`. To avoid confusion, RSpec 3 added an `expect`-style way
of writing one-liners:

    it { is_expected.to validate_presence_of(:name) }

According to Myron Marston:

> Some users have expressed confusion about how this should relates to the
> expect syntax and if you can continue using it. It will continue to be
> available in RSpec 3 (again, regardless of your syntax configuration), but
> we’ve also added an alternate API that is a bit more consistent with the
> expect syntax

From: [New API for
one-liners](http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3#new_api_for_oneliners_)

A proposal was made to switch to using the new `is_expected.to` syntaxin [this
pull request](#215). However, responses
were mixed. Given the lack of consensus one way or the other, let's remove the
guideline entirely and let each project decide which syntax to use.

Author: JoelQ

style/testing/README.md

@@ -8,13 +8,11 @@ Testing
 * Separate setup, exercise, verification, and teardown phases with newlines.
 * Use RSpec's [`expect` syntax].
 * Use RSpec's [`allow` syntax] for method stubs.
-* Use `should` shorthand for [one-liners with an implicit subject].
 * Use `not_to` instead of `to_not` in RSpec expectations.
 * Prefer the `have_css` matcher to the `have_selector` matcher in Capybara assertions.
 
 [`expect` syntax]: http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
 [`allow` syntax]: https://github.com/rspec/rspec-mocks#method-stubs
-[one-liners with an implicit subject]: https://github.com/rspec/rspec-expectations/blob/master/Should.md#one-liners
 [predicate-example]: predicate_tests_spec.rb
 
 Acceptance Tests

style/testing/unit_test_spec.rb

@@ -1,5 +1,4 @@
 describe SomeClass do
-
   context "when defining a subject" do
     # GOOD
     # it's okay to define a `subject` here: