Ref: #647
Ref: ruby/rubygems#6490

Older rubygems are executing `extconf.rb` with a broken `$LOAD_PATH`
causing the `json` gem native extension to be loaded with the stdlib
version of the `.rb` files.

This fails with

```
json/common.rb:82:in `initialize': wrong number of arguments (given 1, expected 0) (ArgumentError)
```

Since this is just for `extconf.rb` we can probably just accept that
extra argument and ignore it.

The bug was fixed in rubygems 3.4.9 / 2023-03-20

Fix: #646

Since both `json` and `json_pure` expose the same files, if the
versions don't match, the native extension may be loaded with Ruby
code that don't match and is incompatible.

By doing the `require json/ext/generator/state` from C we ensure
we're at least loading that.

But this is a dirty workaround for the 2.7.x branch, we should
find a better way to fully isolate the two gems.

This actually never worked, because the test was always testing
the ext version from the stdlib, never the pure version nor the
current ext version.

Workaround rubygems $LOAD_PATH bug

Prior to 2.7.3, `JSON::Ext::Parser` would only take kwargs.
So if json_pure 2.7.4 is loaded with `json <= 2.7.2` (or stdlib)
it blows up.

Ref: #650
Fix: #651

Instantiate Parser with a kwsplat

Fix: #653

I don't think this was really fully supported in the past, but
it kinda worked with some of the implementations.

Handle all formatting configs potentially being `nil`.

Fix: #460

The various `to_json` methods must rescue exceptions
to free the buffer.

```
require 'json'

data = 10_000.times.to_a << BasicObject.new
20.times do
  100.times do
    begin
      data.to_json
    rescue NoMethodError
    end
  end
  puts `ps -o rss= -p #{$$}`
end
```

```
 20128
 24992
 29920
 34672
 39600
 44336
 49136
 53936
 58816
 63616
 68416
 73232
 78032
 82896
 87696
 92528
 97408
102208
107008
111808
```

Fix: #667

This is yet another behavior on which the various implementations
differed, but the C implementation used to call `to_json` on String
subclasses used as keys.

This was optimized out in e125072
but there is an Active Support test case for it, so it's best to
make all 3 implementation respect this behavior.

Add tests for the behavior of JSON.generate with base types subclasses

Followup: #633

That's what was raised historically. You could argue that this new
exception is more precise, but I've encountered some real production
code that expected the old behavior and that was broken by this change.

[2.7.x] Raise JSON::GeneratorError instead of Encoding::UndefinedConversionError