Create current_path arrays on read

[rmosolgo]

Currently, path.dup is one of the biggest object allocators at runtime. The fact is, that value is rarely used. It's only used by the runtime to add paths to errors, and it's exposed via extras: [:path], context[:current_path], and in trace payloads as path: ....

This PR creates path on-demand for extras: [:path] and context[:current_path] and removes it from trace payloads. (Those traces also get context, so code that used data[:path] could use data[:context][:current_path] instead.)

In my silly-large, all-overhead benchmark, this reduces allocations dramatically (ymmv 🍻):

  Calculating -------------------------------------
  Querying for 1000 objects
-                           4.024  (± 0.0%) i/s -     21.000  in   5.225396s
+                           4.372  (± 0.0%) i/s -     22.000  in   5.034931s

  ==================================
    Mode: wall(1)
    Samples: 511904 (42.93% miss rate)
-  GC: 5795 (1.28%)
+  GC: 3013 (0.65%)
  ==================================

- Total allocated: 11635600 bytes (127485 objects)
+ Total allocated: 7155360 bytes (45479 objects)


  allocated objects by class
  -----------------------------------
-      92274  Array
       17108  Hash
+      10270  Array
        8044  Proc

TODO:

• Any edge case tests breaking?
• it seems like using current_path in ScopedContext will remove any performance gain, since Context#[] calls ScopedContext#key?. Make this not so.
• Does graphql-metrics use data[:path]?
  • Yes, but interestingly, a visitor-style path would work here: https://github.com/Shopify/graphql-metrics/blob/b91ad8be9c1965bfdc09c8b516f81563d66b3590/lib/graphql/metrics/tracer.rb#L173
  • Addressed in Support graphql-ruby's new tracing API (backwards compatible) Shopify/graphql-metrics#66
• Consider releasing this change while still populating data[:path] for compatibility, or rolling this into 2.1, or adding a compat module for tracers which puts data[:context][:current_path] into data[:path]
  • Done, see LegacyTrace