Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation

When the `:DoNotReverseLookup` option was originally added to `WEBrick::Config::General` hash in [this commit](https://github.com/ruby/ruby/commit/0d8a0904d93e9600ccd095eabd5e4165c15987ff), the intent was to set `sock.do_not_reverse_lookup` to true **only if** the value of `:DoNotReverseLookup` is **truthy**. Here is the original implementation in webrick/server.rb in that original commit:
```
if @config[:DoNotReverseLookup]
  sock.do_not_reverse_lookup = true
end
```
However, at a later point in time, this code in webrick/server.rb got inadvertently simplified to this:
```
sock.do_not_reverse_lookup = config[:DoNotReverseLookup]
```
This new code does not represent the original intent of the `:DoNotReverseLookup` option. Since `:DoNotReverseLookup` is `nil` by default, this code effectively sets `sock.do_not_reverse_lookup` to **false** unless `:DoNotReverseLookup` is **explicitly** set to true. The original code left `sock.do_not_reverse_lookup` alone unless `:DoNotReverseLookup` was explicitly set to true. When left alone, `sock.do_not_reverse_lookup` would naturally default to the global `Socket.do_not_reverse_lookup` value currently in effect. And since the default value of `Socket.do_not_reverse_lookup` is true, `sock.do_not_reverse_lookup` would be **true** as well, which is the opposite of the result we are currently getting.

This is a very subtle and insidious bug, since reverse look-up rarely causes slowness in development, but it becomes an intermittent bug in production, depending on the host's network environment. This strange intermittent slowness problem is then very difficult to trace back to its root cause in WEBrick's default configuration.

This pull request resolves the issue and provides test coverage for the `:DoNotReverseLookup` option based on the following expected behavior:
```
+--------------------------------------------------------------------------+
|        Expected interaction between Socket.do_not_reverse_lookup         |
|            and WEBrick::Config::General[:DoNotReverseLookup]             |
+----------------------------+---------------------------------------------+
|                            |WEBrick::Config::General[:DoNotReverseLookup]|
+----------------------------+--------------+---------------+--------------+
|Socket.do_not_reverse_lookup|     TRUE     |     FALSE     |     NIL      |
+----------------------------+--------------+---------------+--------------+
|            TRUE            |     true     |     false     |     true     |
+----------------------------+--------------+---------------+--------------+
|            FALSE           |     true     |     false     |     false    |
+----------------------------+--------------+---------------+--------------+
```

@nobu Well, that's a good question. I thought about it too, but decided that the test should be self-contained in case the default for this option changes in the future. Currently, we are **not** *without* `:DoNotReverseLookup` - it *exists* in the config hash by default, and the value is `nil`: https://github.com/ruby/ruby/blob/trunk/lib/webrick/config.rb#L36

So, should the test make assumptions about the default value of `:DoNotReverseLookup`, or should it be explicit about it?