also:
 - makes test dependencies obvious
 - makes tests runnable from within subfolders

Follow up to https://github.com/rails/rails/pull/37849#issuecomment-560557239.

Without this, `0.days` is considered as `0.seconds` due to #31310.
We should not lose the original parts.

Related #37839.

Sometimes divisions of `ActiveSupport::Duration` makes the instance's
parts attribute empty, but it has a value actually (e.g. `(1.minute /
60) # => @value=1 (second), but empty parts`).

In that case we should respect `value` as the source of seconds.

```ruby
(1.day / 24).inspect   #=> "0 seconds"
(1.day / 24).to_i      #=> 3600
(1.day / 24) == 1.hour #=> true
(1.hour).inspect       #=> "1 hour"
(1.hour).parts         #=> {:hours=>1}
(1.day / 24).parts     #=> {}
```

Sometimes divisions of `ActiveSupport::Duration` make the instance's `parts` attribute empty. But these instances are not always 0 seconds.

Related to #31310 and #31302

Rational values are move precise than float values so when comparing
rationals values may be off by a few units that are hard to assert
equality. Let's make sure we are comparing the float value with float
values.

These failed previously because decimals floats don't make perfect
decimal numbers and Rational represents them exactly (either as decimal
or the inexact float value).

This changes the asserts to match that value.

We were using picoseconds as precision but some Ruby implementations
only support up to nanoseconds. Since that much precision was not needed
to test the feature I decreased the precision.

Address complaints by CodeClimate

Address review feedback

- Fixes https://github.com/rails/rails/issues/36451

    Prevent `ActiveSupport::Duration.build(value)` from creating instances of
    `ActiveSupport::Duration` unless `value` is of type `Numeric`.

    Addresses the errant set of behaviours described in #37012 where
    `ActiveSupport::Duration` comparisons would fail confusingly
    or return unexpected results when comparing durations built from instances of `String`.

    Before:

        small_duration_from_string = ActiveSupport::Duration.build('9')
        large_duration_from_string = ActiveSupport::Duration.build('100000000000000')
        small_duration_from_int = ActiveSupport::Duration.build(9)

        large_duration_from_string > small_duration_from_string
            => false

        small_duration_from_string == small_duration_from_int
            => false

        small_duration_from_int < large_duration_from_string
            => ArgumentError (comparison of ActiveSupport::Duration::Scalar
                    with ActiveSupport::Duration failed)

        large_duration_from_string > small_duration_from_int
            => ArgumentError (comparison of String with ActiveSupport::Duration failed)

    After:

        small_duration_from_string = ActiveSupport::Duration.build('9')
            => TypeError (can't build an `ActiveSupport::Duration` from a `String`)

Added the ability to initialize `thread_mattr_*` methods with default
values like so:

``` ruby
  class MyClass
    thread_attr_reader :foo, default: :foo
    thread_attr_writer :bar, default: :bar
    thread_attr_accessor: baz do
      "baz"
    end
  end
```

This is consistent with the api exposed by `mattr_accessor`.

In case a negative position is provided that exceeds the size of the
string, we're relying on -1 returned from max to get 0 length by + 1
and let [] with a 0 length returning "" for us.

E.g. "hello".to(-7), where -7 + 5 size = -2. That's
lower than -1, so we use -1 instead and + 1 would turn it into 0.

Instead allow outer bounds access and always return "".

Exclude missing marshal_dump and _dump methods from being delegated to
an object's delegation target via the delegate_missing_to extension.
This avoids unintentionally adding instance variables to an object
during marshallization, should the delegation target be a method which
would otherwise add them.

In current versions of Ruby, a bug exists in the way objects are
marshalled, allowing for instance variables to be added or removed
during marshallization (see https://bugs.ruby-lang.org/issues/15968).
This results in a corrupted serialized byte stream, causing an object's
instance variables to "leak" into subsequent serialized objects during
demarshallization.

In Rails, this behavior may be triggered when marshalling an object that
uses the delegate_missing_to extension, if the delegation target is a
method which adds or removes instance variables to an object being
marshalled - when calling Marshal.dump(object), Ruby's built in behavior
will check whether the object responds to :marshal_dump or :_dump, which
in turn triggers the delegation target method in the
responds_to_missing? function defined in
activesupport/lib/active_support/core_ext/module/delegation.rb

While future versions of Ruby will resolve this bug by raising a
RuntimeError, the underlying cause of this error may not be readily
apparent when encountered by Rails developers. By excluding marshal_dump
and _dump from being delegated to an object's target, this commit
eliminates a potential cause of unexpected behavior and/or
RuntimeErrors.

Fixes #36522

Tests are also only on the `Time` class

Update doc forgetting to erase when moved

Update guide `Date` class to `Time` class and defined file

Update guide correction omission

We sometimes say "✂️ newline after `private`" in a code review (e.g.
https://github.com/rails/rails/pull/18546#discussion_r23188776,
https://github.com/rails/rails/pull/34832#discussion_r244847195).

Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style
`EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059).

That cop and enforced style will reduce the our code review cost.

I frequently find myself having to .compact but for blank. which means
on an array reject(&:blank?) (this is fine), or,
on a hash `.reject { |_k, v| v.blank? }` which is slightly more
frustrating and i usually write it as .reject(&:blank?) first and am
confused when it's trying to check if the keys are blank.

I've added the analagous .compact_blank! where there's a reject! to
build on (there's also a reject! in Set, but there's no other core_ext
touching Set so i've left that alone)

attachment

Removes unnecessary conditional and method call for significant
performance improvement.  As a side effect, this fixes an unexpected
behavior where passing a limit of 0 would return a frozen string.

This also implements the Rails 6.1 intended behavior with regards to
negative limits, and removes the previous deprecation warnings.

String#first Comparison:
  new:   3056515.0 i/s
  old:   1943310.2 i/s - 1.57x slower

String#last Comparison:
  new:   2691919.0 i/s
  old:   1924256.6 i/s - 1.40x slower

(Note: "old" benchmarks have deprecation warnings commented out, for a
more fair comparison.)

* Add test asserting truncate returns unfrozen string

* Ensure strings returned from truncate are not frozen

This fixes an issue where strings too short to be truncated were
returned unfrozen, where as long-enough strings were returned
frozen. Now retuned strings will not be frozen whether or not
the string returned was shortened.

* Update changelog w/ new truncate behavior description

[Jordan Thomas + Rafael Mendonça França]

Before:
```ruby
(1..10).cover?(1...11) => false
```

After:
```ruby
(1..10).cover?(1...11) => true
```

See https://git.io/fjTtz for the commit against Ruby core that added
support for Range arguments, with similar handling of this case.

In #10634 the behavior of Time#advance was changed to maintain a
proleptic gregorian calendar for dates before calendar reform. However
it didn't full address dates a long time before calendar reform and
they gradually drift away from the proleptic calendar the further you
go back in time. Fix this by always converting the date to gregorian
before calling advance which sets the reform date to -infinity.

Also add tests for parametrize and transliterate

Accommodate case-insensitive filesystems and database collations.

Rails 6 requires Ruby 2.5, which introduces `FrozenError`
https://docs.ruby-lang.org/en/2.5.0/NEWS.html

Related to #31520

See https://travis-ci.org/rails/rails/jobs/470890129#L2361

Currently we sometimes find a redundant begin block in code review
(e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205).

I'd like to enable `Style/RedundantBegin` cop to avoid that, since
rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5
(https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with
that situation than before.

- Fix a few deprecation warnings
- Remove testing of `Hash#slice`
- Imporve test of `Hash#slice!`
- Remove mention about `Hash#slice` from the guide