Scrape out monkey patching

http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode

> we do want to encourage people to switch to the new syntax, so we plan to make RSpec 3 print a warning on first usage of any the old syntax methods (should, should_not, should_receive, etc) unless the should syntax has been explicitly enabled. This should nudge folks towards the new syntax while keeping RSpec friendly to new users and will pave the way for the old syntax to be disabled by default in RSpec 4.

> zero-monkey-patching mode for RSpec...  We plan for these config options to become the defaults in RSpec 4.0, so that RSpec 4.0 will have zero monkey patching out of the box.

As for "disabled by default" vs "completely removed" and "default, out
of the box" vs "impossible" I can only say that RSpec 4 was probably planned to
be released earlier, as:

> we'll probably be dropping support for 1.8.7 in RSpec 4

but we've also dropped 1.9, 2.0, 2.1 and 2.2

rspec/rspec-core#2301 (comment)

> In RSpec 4, we plan to extract all monkey patching from RSpec and move it into a separate gem, so that monkey patching is opt-in instead of opt-out and users have to explicitly install and load a gem to get it.

`rspec-should` (or `rspec-monkey` as it's also about exposing example
group DSL in the top-level/Module?) will be released later.

Those using the monkey-patched `should` syntax are not encouraged to
update to RSpec 4 until this gem is extracted.

Those using the globally-exposed DSL are encouraged to use
`RSpec.describe`/`RSpec.shared_examples_for` instead.

Changelog.md

@@ -4,6 +4,7 @@
 Breaking Changes:
 
 * Ruby < 2.3 is no longer supported. (Phil Pirozhkov, #1231)
+* Extract monkey-patching `should*` syntax and globally-exposed DSL. (Phil Pirozhkov, #1245)
 
 Enhancements:
 

README.md

@@ -219,16 +219,15 @@ expect(
 ## `should` syntax
 
 In addition to the `expect` syntax, rspec-expectations continues to support the
-`should` syntax:
+non-monkey patching `should` syntax:
 
 ```ruby
-actual.should eq expected
-actual.should be > 3
-[1, 2, 3].should_not include 4
+subject(:number) { 4 }
+it { should eq(4) }
+it { should be > 3 }
+it { should_not be_odd }
 ```
 
-See [detailed information on the `should` syntax and its usage.](https://github.com/rspec/rspec-expectations/blob/main/Should.md)
-
 ## Compound Matcher Expressions
 
 You can also create compound matcher expressions using `and` or `or`:

features/.nav

@@ -36,7 +36,6 @@
 - customized_message.feature
 - diffing.feature
 - implicit_docstrings.feature
-- syntax_configuration.feature
 - test_frameworks:
   - test_unit.feature
 - Changelog.md

features/built_in_matchers/README.md

@@ -1,13 +1,11 @@
 rspec-expectations ships with a number of built-in matchers. Each matcher can be used
 with `expect(..).to` or `expect(..).not_to` to define positive and negative expectations
-respectively on an object. Most matchers can also be accessed using the `(...).should` and
-`(...).should_not` syntax; see [using should syntax](https://github.com/rspec/rspec-expectations/blob/main/Should.md) for why we recommend using `expect`.
+respectively on an object.
 
 e.g.
 
     expect(result).to   eq(3)
     expect(list).not_to be_empty
-    pi.should be > 3
 
 ## Object identity