`silence_stderr`, `silence_stream`, `capture` and `quietly`.

This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:

* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.

For this purpose, this commit introduces a Rails configuration option:

```ruby
config.active_support.halt_callback_chains_on_return_false
```

For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:

```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```

For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.

Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.

Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.

A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931

After this commit, returning `false` in a callback will display a deprecation
warning to make developers aware of the fact that they need to explicitly
`throw(:abort)` if their intention is to halt a callback chain.

This commit also patches two internal uses of AS::Callbacks (inside
ActiveRecord and ActionDispatch) which sometimes return `false` but whose
returned value is not meaningful for the purpose of execution.

In both cases, the returned value is set to `true`, which does not affect the
execution of the callbacks but prevents unrequested deprecation warnings from
showing up.

This commit changes arguments and default value of CallbackChain's :terminator
option.

After this commit, Chains of callbacks defined **without** an explicit
`:terminator` option will be halted as soon as a `before_` callback throws
`:abort`.

Chains of callbacks defined **with** a `:terminator` option will maintain their
existing behavior of halting as soon as a `before_` callback matches the
terminator's expectation. For instance, ActiveModel's callbacks will still
halt the chain when a `before_` callback returns `false`.

`MissingSourceFile` was just an alias to `LoadError` and was not
being raised inside the framework.

They are already present on Ruby 2.2

This constant may be define for auxiliar gems like rails-html-sanitizer
and these methods call will fail.

This code was there just to convert entries generated in Rails
4.0.0.beta1 applications to a supported format.

It is almost unlikely that any existent application have this cache
entry format in their caches at the point that Rails 5 will be released
so we don't need this code anymore.

We should convert when @v is defined not @value.

The test was calling value first that already converts the entry so we
are not catching this bug.

When trying to access a character on a string buffer object via `:[]`, if the object being accessed currently returns `html_safe?` as true,
we used to set  `@html_safe` variable as true on new object created. When doing something like

x = 'Hello'.html_safe
x[/a/, 1]

would throw an error on ruby 2.2, since when nothign gets matched nil is returned by the code and it tries to set   `@html_safe` value to true,
which would error since starting 2.2 nil is frozen.

This change adds a safety net to avoid setting `@html_safe = true` on frozen objects.

Fixes #18235

Add examples for missing_name, missing_name?

[ci skip]

Also add doc examples for `Object.nil`.

[ci skip]

this should be `:nodoc:` in order to be parsed.

Document `test_order` and `test_order=` from `ActiveSupport::TestCase`.

[ci skip]

Add docs for `minutes`, `hours`, `days`, `weeks` and `fortnights`.
Fix docs for `in_milliseconds`.

[ci skip]

@rafaelfranca suggested in f7c7bcd9 that code examples should display
the result after  `# =>` and not after `#=>`.

This commit replaces *all* the occurrences of `#=>` in the code documentation
(mostly added by me 😭) with the suggested `# =>`.

Add docs for `kilobytes`, `megabytes`, `gigabytes`, `terabytes`,
`petabytes` and `exabytes`. Fix docs for `bytes`.

[ci skip]

Also improves docs for `Time#find_zone!`

[ci skip]

Stems from comments by @zzak on e07f3ddc:

* https://github.com/rails/docrails/commit/e07f3ddcac394d2a8dc23fc571318b7e8c2497b1#commitcomment-9015634
* https://github.com/rails/docrails/commit/e07f3ddcac394d2a8dc23fc571318b7e8c2497b1#commitcomment-9015639

[ci skip]

[ci skip]

Stems from [Google group discussion](https://groups.google.com/forum/#!topic/rubyonrails-core/jSPbP-TNLb0).

Currently `AS::TimeWithZone` has two methods to add an interval to a time:
`+(other)` and `since(other)` ([docs](http://edgeapi.rubyonrails.org/classes/ActiveSupport/TimeWithZone.html)).

The two methods are "pretty much" equivalent in every case:

1. When adding any interval to an `AS::TimeWithZone` representing a `Time`:

  ```ruby
  t = Time.now.in_time_zone       #=> Thu, 04 Dec 2014 18:56:28 EST -05:00
  t + 1 == t.since(1)             #=> true
  t + 1.day == t.since(1.day)     #=> true
  t + 1.month == t.since(1.month) #=> true
  ```

2. When adding any interval to an `AS::TimeWithZone` representing a `Date`:

  ```ruby
  d = Date.today.in_time_zone     #=> Thu, 04 Dec 2014 00:00:00 EST -05:00
  d + 1 == d.since(1)             #=> true
  d + 1.day == d.since(1.day)     #=> true
  d + 1.month == d.since(1.month) #=> true
  ```

3. When adding any interval to an `AS::TimeWithZone` representing a `DateTime`:

  ```ruby
  dt = DateTime.now.in_time_zone    #=> Thu, 04 Dec 2014 18:57:28 EST -05:00
  dt + 1 == dt.since(1)             #=> true
  dt + 1.day == dt.since(1.day)     #=> true
  dt + 1.month == dt.since(1.month) #=> false
  ```

As you can see, the only case in which they differ is when the interval added
to a `DateTime` is in a format like `1.month`.

However, this usage of "since" is explicitly discouraged by the
[documentation of `DateTime#since`](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/date_time/calculations.rb#L86L88):

> Returns a new DateTime representing the time a number of seconds since the instance time.
> Do not use this method in combination with x.months, use months_since instead!

And indeed, following this recommendation the correct result is returned:

```ruby
dt + 1.month == dt.months_since 1 #=> true
```

Therefore, my proposal is to remove the method definition of `TimeWithZone#since`
and instead replace it with a simple `alias_method :since, :+`.

The rationale is that the only case where they differ is a case that is
explicitly discouraged as "wrong".

In my opinion, having two methods named `since` and `+` and having to figure
out exactly what the difference is makes the codebase more confusing.

However, I understand this PR is "subjective", so if you feel like it's better
to ignore this, feel free to close the PR.

Thanks!

`define_callbacks` from `ActiveSupport::Callbacks` accepts the
`:skip_after_callbacks_if_terminated` option since #4866 but the option
is not tested anywhere.

This commit adds tests and fixes documentation for the option, making it clear
that halting a callback chain only stops following `before_` and `around_`
callbacks by default.

Adds examples and keeps coherent with the documentation of the
similar method `seconds_until_end_of_day`. [ci skip]

The example was taken from the commit message 676d6a65.

[ci skip]

[ci skip]

[ci skip]

Complements #17727 and closes ee73d9ff.

@lleger How do you feel about this?

This is the project guideline and the reasons are:

* That follows standard Ruby semantics.
* Allows the implementation to avoid artificial code like !! or something ? true : false
* You do not need to rely on the exact type of 3rd party code. For
example, if your method returns str.end_with?('foo') you do not need to
make sure end_with? returns a singleton. Your predicate just propagates
predicate semantics up regardless of what end_with? returns.