Fix Thread blocking count drifting across Fiber switches - #9607

Fiber.current_scheduler reads the Thread's blocking count, and it drifted both ways: Fiber#resume decremented a target that exchangeWithFiber had already decremented, and the hand-back was counted twice. Account like MRI's fiber_switch instead, where each Fiber adjusts only for itself.

Adds core/fiber/current_scheduler_spec.rb from ruby/spec#1388 and drops the tag added in #9604. Also adds additional root Fiber specs from ruby/spec#1390.

Not as simple a change as #9604, but this should fix the blocking count drift.

Of the added tests, 5 of 11 fail on master. Failing ones:

returns nil inside a blocking Fiber nested in a non-blocking Fiber
returns nil inside Fiber.blocking in a non-blocking Fiber
returns nil on the root Fiber after a blocking Fiber has finished
returns nil on the root Fiber after a blocking Fiber has raised
returns nil on the root Fiber after a blocking Fiber has been killed

Oneliner to test the drift:
jruby -e 'require "jruby"; f = org.jruby.RubyThread.java_class.declared_field("blockingCount"); f.accessible = true; c = -> { f.get(JRuby.reference(Thread.current)) }; puts "before: #{c.call}"; 20_000.times { Fiber.new(blocking: true) { }.resume }; puts "after: #{c.call}"'

Master:
before: 1
after: -19999

This branch:
before: 1
after: 1