Make Kernel#silence_stream & Kernel#capture thread safe, stop turning STDOUT into /dev/null.

During an upgrade from Rails 3 -> 4, I noticed our log output was completely 'freezing', both in console and file logs whenever running features.

In the end this was tracked down to https://github.com/rails/activerecord-session_store running a `Kernel#quietly` command when finding the session. It looks like `silence_stream` isn't thread safe.

The issue being: 

https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/kernel/reporting.rb#L46

```
 def silence_stream(stream)
    old_stream = stream.dup
    stream.reopen(RbConfig::CONFIG['host_os'] =~ /mswin|mingw/ ? 'NUL:' : '/dev/null')
    stream.sync = true
    yield
  ensure
    stream.reopen(old_stream)
  end
```

If another thread has picked up a global `STDOUT` and replaced it via `reopen` to `dev/null` then the last thread wins, effectively leaving `STDOUT` as `/dev/null` and giving the appearance of anything using `STDOUT` such as test output as stopping.

I've given the test a shot, and can make it consistently fail without the synchronise changes. If anyone has any tips on how to test it I'd love to know, I'm not sure this is the best way.

The same issue was present for `capture(stream)` also, and the scenario of using both `capture` and `silence_stream` in multiple threads together. As such I've added another commit that shares the same monitor lock and tested the same error produced from `capture(stream)`. I did write a test for the combination of both (if they both have their own unique thread safe monitor and not shared), but felt it was overkill, I can add back if you'd like.