While using `assert_changes`, I came across some unexpected behavior:
if you provide a `to:` argument, and the expression matches but didn't
actually change, the assertion will pass.

The way `assert_changes` reads, I assumed that it would both assert
that there was any change at all, _and_ that the expression changed to
match my `to:` argument.

In the case of just a `from:` argument, `assert_changes` does what I
expect as well. It asserts that the before value `=== from` and that
the after value changed.

My key change is that `assert_changes` will now _always_ assert that
expression changes, no matter what combination of `from:` and `to:`
arguments

Currently, credentials does not check the format when saving. As a result,
incorrect data as yaml is also saved.
If credentials is used in config files., an error will occur in credential
yaml parsing before edit, and will not be able to edit it.

In order to prevent this, verify the format when saving.

Related: #30851

[ci skip]

This is no longer used since fd6aaaa0.

## Summary

RuboCop 0.51.0 was released.
https://github.com/bbatsov/rubocop/releases/tag/v0.51.0

And rubocop-0-51 channel is available in Code Climate.
https://github.com/codeclimate/codeclimate-rubocop/issues/109

This PR will bump RuboCop to 0.51.0 and fixes the following new
offenses.

```console
% bundle exec rubocop
Inspecting 2358 files

(snip)

Offenses:

actionpack/lib/action_controller/metal/http_authentication.rb:251:59: C:
Prefer double-quoted strings unless you need single quotes to avoid
extra backslashes for escaping.
          [key.strip, value.to_s.gsub(/^"|"$/, "").delete('\'')]
                                                          ^^^^
activesupport/test/core_ext/load_error_test.rb:8:39: C: Prefer
double-quoted strings unless you need single quotes to avoid extra
backslashes for escaping.
    assert_raise(LoadError) { require 'no_this_file_don\'t_exist' }
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

2358 files inspected, 2 offenses detected
```

In #11474 we prevented TWZ ranges being iterated over which matched
Ruby's handling of Time ranges and as a consequence `include?` stopped
working with both Time ranges and TWZ ranges. However in
ruby/ruby@b061634 support was added for `include?` to use `cover?` for
'linear' objects. Since we have no way of making Ruby consider TWZ
instances as 'linear' we have to override `Range#include?`.

Fixes #30799.

Seeing the previously issued PRs about it, we can avoid the `nil`
comparisons that can happen in `assert_changes` by using plain `assert`
calls.

This is to avoid a deprecation warning about comparing `nil` values in
`assert_equal` for Minitest 5 and a crash in Minitest 6.

You can see the preparations done in [`assert_equal`][ae]. You can also
see that [`assert`][a] does not care about `nil`s.

[ae]: https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest/assertions.rb#L159-L188
[a]: https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest/assertions.rb#L131-L142

These changes resolve a deprecation warning in `assert_no_changes`
when asserting that an expression evaluates to `nil` before and after
the passed block is evaluated.

The smallest demonstration of this edge case:

```ruby
assert_no_changes "nil" do
  true # noop
end
```

Under the covers, this is evaluating

```ruby
assert_equal nil, nil
```

Minitest 5 issues a deprecation warning, and Minitest will fail
completely.

For additional context, the motivations and implications of this change
to Minitest have been discussed at length in [seattlerb/minitest#666][].

[seattlerb/minitest#666]: https://github.com/seattlerb/minitest/issues/666

Acronym inflections are stored with lowercase keys in the hash but
the match wasn't being lowercased before being looked up in the hash.
This shouldn't have any performance impact because before it would
fail to find the acronym and perform the `downcase` operation anyway.

Fixes #31052.

Trés -> Très 
https://fr.wiktionary.org/wiki/tr%C3%A8s

These methods unused since 55336960.

Follow up of #31004.

Related to #30972

The documentation wrongly suggests that Time extensions to Numeric include
methods months and years, when these belong to Integer.

Update both classes and guides.

activesupport/lib/active_support/core_ext/object/acts_like.rb
acts_like?

Add a case statement to use direct symbols instead of string
interpolation for the three scenarios I found in the Rails codebase:
time, date, and string.

For time/date/string, this change prevents two string allocations for
each time the method is called and speeds up the method by ~2.7x. For
other arguments, there is no memory difference and performance
difference is within margin of error.

begin
  require "bundler/inline"
rescue LoadError => e
  $stderr.puts "Bundler version 1.10 or later is required. Please update
                your Bundler"
  raise e
end

gemfile(true) do
  source "https://rubygems.org"

  gem "rails", github: "rails/rails"
  gem "arel", github: "rails/arel"
  gem "benchmark-ips"
end

def allocate_count
  GC.disable
  before = ObjectSpace.count_objects
  yield
  after = ObjectSpace.count_objects
  after.each { |k,v| after[k] = v - before[k] }
  after[:T_HASH] -= 1 # probe effect - we created the before hash.
  GC.enable
  result = after.reject { |k,v| v == 0 }
  GC.start
  result
end

class Object
  def fast_acts_like?(duck)
    case duck
    when :time
      respond_to? :acts_like_time?
    when :date
      respond_to? :acts_like_date?
    when :string
      respond_to? :acts_like_string?
    else
      respond_to? :"acts_like_#{duck}?"
    end
  end
end

puts
puts " acts_like? ".center(80, '=')
puts

obj = ''.freeze

%i(time date string super_hacka).each do |type|
  puts " #{type} ".center(80, '=')

  puts " Memory Usage ".center(80, "=")
  puts

  puts "value.acts_like?"
  puts allocate_count { 1000.times { obj.acts_like?(type) } }

  puts "value.fast_acts_like?"
  puts allocate_count { 1000.times { obj.fast_acts_like?(type) } }

  puts
  puts " Benchmark.ips ".center(80, "=")
  puts

  Benchmark.ips do |x|
    x.report("acts_like?")      { obj.acts_like?(type) }
    x.report("fast_acts_like?") { obj.fast_acts_like?(type) }
    x.compare!
  end
end

================================== acts_like? ==================================

===================================== time =====================================
================================= Memory Usage =================================

value.acts_like?
{:FREE=>-1983, :T_STRING=>2052, :T_IMEMO=>1}
value.fast_acts_like?
{:FREE=>-1}

================================ Benchmark.ips =================================

Warming up --------------------------------------
          acts_like?   104.281k i/100ms
     fast_acts_like?   155.523k i/100ms
Calculating -------------------------------------
          acts_like?      1.688M (±10.7%) i/s -      8.342M in   5.003804s
     fast_acts_like?      4.596M (±12.1%) i/s -     22.551M in   5.000124s

Comparison:
     fast_acts_like?:  4596162.4 i/s
          acts_like?:  1688163.8 i/s - 2.72x  slower

===================================== date =====================================
================================= Memory Usage =================================

value.acts_like?
{:FREE=>-2001, :T_STRING=>2000}
value.fast_acts_like?
{:FREE=>-1}

================================ Benchmark.ips =================================

Warming up --------------------------------------
          acts_like?    85.372k i/100ms
     fast_acts_like?   166.097k i/100ms
Calculating -------------------------------------
          acts_like?      1.720M (± 8.3%) i/s -      8.537M in   5.001003s
     fast_acts_like?      4.695M (±10.1%) i/s -     23.254M in   5.010734s

Comparison:
     fast_acts_like?:  4695493.1 i/s
          acts_like?:  1719637.9 i/s - 2.73x  slower

==================================== string ====================================
================================= Memory Usage =================================

value.acts_like?
{:FREE=>-2001, :T_STRING=>2000}
value.fast_acts_like?
{:FREE=>-1}

================================ Benchmark.ips =================================

Warming up --------------------------------------
          acts_like?   100.221k i/100ms
     fast_acts_like?   182.841k i/100ms
Calculating -------------------------------------
          acts_like?      1.706M (± 7.3%) i/s -      8.519M in   5.022331s
     fast_acts_like?      3.968M (±22.8%) i/s -     18.650M in   5.006762s

Comparison:
     fast_acts_like?:  3967972.9 i/s
          acts_like?:  1705773.7 i/s - 2.33x  slower

================================= super_hacka ==================================
================================= Memory Usage =================================

value.acts_like?
{:FREE=>-2004, :T_STRING=>2002, :T_SYMBOL=>1}
value.fast_acts_like?
{:FREE=>-2003, :T_STRING=>2001, :T_SYMBOL=>1}

================================ Benchmark.ips =================================

Warming up --------------------------------------
          acts_like?   100.344k i/100ms
     fast_acts_like?   101.690k i/100ms
Calculating -------------------------------------
          acts_like?      1.617M (± 7.5%) i/s -      8.128M in   5.055285s
     fast_acts_like?      1.534M (±10.1%) i/s -      7.627M in   5.031052s

Comparison:
          acts_like?:  1617390.7 i/s
     fast_acts_like?:  1533897.3 i/s - same-ish: difference falls within error

This basically reverts 8da30ad6

In order to keep this method compatible with the Ruby 2.5 version of Hash#slice.
This bahavior is actually slightly incompatibile with previous versions of Active Support
but it might not cause a real problem, since HWIA, the biggest use case of Hash subclassing here,
already overrides `slice` to return another HWIA.

since r60229

Instructions to use `h` or `html_escape` in ERB templates were added to 
`actionpack/lib/action_view/template_handlers/erb.rb` in a1b03493 (Rails 
2.1), but ERB has automatically escaped values since Rails 3.

* Add missing credit
* Add backticks
* Fix indentation
* Remove trailing spaces

And some minor tweaks.

Fixes ActiveSupport::Cache::FileStore#cleanup bug which prevented it from cleaning up the expired cache keys

`new_credentials_configuration` is no longer used since 081a6ac6f7fd929798481f9ee333fb92b441356c.

Follow up of #30728.

See the changelog entry.

Remove `secrets.secret_token` from the bug report templates,
since we don't accept bug reports for Rails versions that
don't support a `secret_key_base`.

[ claudiob & Kasper Timm Hansen ]