Avoid Hash#merge on large subclass schemas

[rmosolgo]

It was already mentioned in the code how a large schema can incur a costly Hash#merge when using .references_to:

graphql-ruby/lib/graphql/schema.rb

Lines 553 to 555 in 9eee764

	# `@own_references_to` can be quite large for big schemas,
	# and generally speaking, we won't inherit any values.
	# So optimize the most common case -- don't create a duplicate Hash.

But the implementation there didn't address when a schema did have some inherited types. In that case, the cost was still paid of merging the hashes, even for a very small query.

We can re-work this, improving an existing implementation of .references_to(type_name), so that the big, merged hash isn't used by GraphQL-Ruby execution, so it's never made at all.

For a small schema with inherited types, it can make a big difference. The benchmark I added here:

-      Run small query      4.586k (± 8.1%) i/s -     23.256k in   5.108886s
+     Run small query      4.879k (± 5.8%) i/s -     24.735k in   5.090457s
... 
- Total allocated: 30656 bytes (278 objects)
+ Total allocated: 27248 bytes (277 objects)

That was one object taking up 10% of memory!

Another thing I noticed was that, because the @references_to Hash was assigning [] to keys by default, GraphQL::Schema could actually have some entries in its Hash. But they might not point at anything -- they might just be misses. So it would cause .merge for a bunch of empty arrays 😩

TODO:

• check large query benchmarks -- did this slow them down? Perhaps cache Warden#referenced?
  • The other benchmarks look the same. And they didn't have any reduction in memory, presumably because they didn't have any inherited references_to so they weren't performing the merge to start with.