🎉 🍻

We went back to `Thread.current[]` in 33e11e59.

This reverts commit 301f4382 per @matthewd on https://github.com/rails/rails/pull/22630/files#r47997074

We call the thread variable accessors on `Thread.current`, which matches Ruby's 
documentation:

http://ruby-doc.org/core-2.2.0/Thread.html#method-i-thread_variable_get

Fix these to stay `current` ( ͡° ͜ʖ ͡°)

[ci skip]

[ci skip]

Add thread_m/cattr_accessor/reader/writer suite of methods for declaring class and module variables that live per-thread

When setting the Rails logger to log to STDOUT, it would broadcast the
log twice in development. This adds a setting that will prevent messages
from being broadcast to multiple logs, while still allowing calls to
`#close`, `#level=`, `#progname=`, and `#formatter=` to be broadcasted.

Fixes #14769, #11415

See the rationale in the comment present in this patch.

Corrects the time comparison to be `Time.now < time` which allows the user to
be set only when the current time is less than the 2 week window given in the
example.

Better English.

The issue is that on the exit from Instrumenter#instrument section,
an Evented listener will run into an error because its thread local
(Thread.current[:_timestack]) has not been set up by the #start
method (this obviously happens because the Evented listeners didn't
exist at the time, since no subscribtion to that section was made yet).

Note: support for subscribing to instrumented sections, while being
inside those instrumented sections, might be removed in the future.

Maybe fixes #21873.

Fixes #22376.

JRuby 9.0.5.0 will support ObjectSpace.each_object against a
class's singleton class, since that's essentially just walking an
internal subclasses structure we already maintain. This test was
too narrow, requiring that each_object support an arbitrary class
but only actually needing it to work against a class's singleton.

This improves performance of Class.descendants by nearly two orders
of magnitude when run against JRuby 9.0.5.0:

```ruby
5.times { puts Benchmark.measure { 100_000.times { Numeric.descendants } } }
```

Before:

```
 11.510000   0.140000  11.650000 ( 10.082384)
  9.990000   0.020000  10.010000 (  9.931233)
 10.520000   0.040000  10.560000 ( 10.502978)
 10.290000   0.030000  10.320000 ( 10.276027)
 10.000000   0.030000  10.030000 (  9.942429)
```

After:

```
  1.380000   0.040000   1.420000 (  0.365850)
  0.210000   0.000000   0.210000 (  0.149574)
  0.180000   0.020000   0.200000 (  0.141094)
  0.140000   0.000000   0.140000 (  0.140634)
  0.190000   0.010000   0.200000 (  0.147962)
```

This method needs to ensure that if a change happens, it is going to be registered.
With this refactor suggested by @matthewd race conditions do not matter because if
no file is watched, nothing is done. And as long as some invocation sets the flag
to true, it will stay true.

The refactor leaves a race condition in which two simultaneous threads that watch
some of the files passed do the actual work in `any?`, whereas the mutex guaranteed
that was done at most once. But this is considered to be a better tradeoff.

listen is calling us from its own thread, we need to synchronize reads and writes to this flag.

Not only does this make for simpler, more obvious code, it's also more performant:

    require 'benchmark/ips'

    module Enumerable
      def old_sum(identity = 0, &block)
        if block_given?
          map(&block).old_sum(identity)
        else
          inject { |sum, element| sum + element } || identity
        end
      end

      def new_sum(identity = 0, &block)
        if block_given?
          map(&block).new_sum(identity)
        else
          inject(:+) || identity
        end
      end
    end

    summable = (1..100).to_a # sum is 5050

    Benchmark.ips do |x|
      x.report("old_sum") { summable.old_sum }
      x.report("new_sum") { summable.new_sum }
      x.compare!
    end

    # Calculating -------------------------------------
    #              old_sum    10.674k i/100ms
    #              new_sum    14.542k i/100ms
    # -------------------------------------------------
    #              old_sum    117.350k (± 7.1%) i/s -    587.070k
    #              new_sum    154.712k (± 3.8%) i/s -    785.268k
    #
    # Comparison:
    #              new_sum:   154712.1 i/s
    #              old_sum:   117350.0 i/s - 1.32x slower

More benchmarks [here](https://gist.github.com/tjschuck/b3fe4e8c812712376648), including summing strings and passing blocks.  The performance gains are less for those, but this version still always wins.

Fixes #22311

A small rewrite in a last attempt at writing obvious and portable code
without manual string manipulation.

Note that Pathname#== uses string comparison on Windows, so if client
code passes "C:\foo" and "c:/foo/bar" the predicate won't see the
former is an ascendant of the latter. Risky business.

This can make use of the FileEventedUpdateChecker, if available.

Whatever the inner loop selects, we already know is a descendant and
can be filtered out right away from dirs_sorted_by_nparts to skip
useless iterations.