[FEATURE] Upstream built-in helpers and modifiers from Ember

[pzuraq]

Upstreams the built-in helpers and modifiers from Ember:

• on
• fn
• array
• hash
• get
• concat

Tests were adapted directly from the existing test suites in Ember, with omissions wherever particular test functionality did not make sense (e.g. integration testing get with <Input/>).

Breaking Changes

• setPath is now required on the global context

[rwjblue]

Current failure is:

not ok 1393 Chrome 87.0 - [2 ms] - [integration] jit :: {{on}} Modifier: SUPPORTS_EVENT_OPTIONS is correct (private API usage)
    ---
        actual: >
            null
        stack: >
                at _loop (http://localhost:7357/153953091774/tests/assets/glimmer-vm.js:18481:21)
                at http://localhost:7357/153953091774/tests/assets/glimmer-vm.js:18491:11
                at suite (http://localhost:7357/153953091774/tests/assets/glimmer-vm.js:18493:9)
                at jitSuite (http://localhost:7357/153953091774/tests/assets/glimmer-vm.js:18407:12)
                at Module.callback (http://localhost:7357/153953091774/tests/assets/tests.js:13379:20)
                at Module.exports (http://localhost:7357/153953091774/tests/assets/loader.js:106:32)
                at requireModule (http://localhost:7357/153953091774/tests/assets/loader.js:27:18)
                at http://localhost:7357/153953091774/tests/index.html?hidepassed:139:11
        message: >
            Expected 0 assertions, but 1 were run
        negative: >
            false
        browser log: |

[rwjblue]

• Why are the various test files empty?
  • packages/@glimmer/integration-tests/test/helpers/array-test.ts
  • packages/@glimmer/integration-tests/test/helpers/fn-test.ts
  • packages/@glimmer/integration-tests/test/helpers/get-test.ts
  • packages/@glimmer/integration-tests/test/helpers/hash-test.ts
  • packages/@glimmer/integration-tests/test/helpers/concat-test.ts
  • packages/@glimmer/integration-tests/test/helpers/array-test.ts

[rwjblue]

I'm curious why we'd actually need setPath, wouldn't all sets end up being setProp (I thought TWB for {{whatever someArg=foo.bar.baz}} we'd be calling setProp for bar['baz'] instead of Ember.set(foo, 'bar.baz'))?

[pzuraq]

This is specifically for {{get}}. In general, when we see a path in Glimmer, we break it down into a chain of references. However, when the path is dynamic, we cannot do that, we have to do it all within a single reference. We already had getPath because there was an instance of this before for getting a path (the key on each) but we never encountered a setPath before. {{get}} can also update the value that is accessed (similar to how mut works), so that's why we need the ability to set a path - it's dynamic and not broken down into pieces.

[rwjblue]

So to clarify, its for (mut (get being used together (since I didn't think that {{something whatever=(get otherThing 'lol.path')}} allowed mutation of otherThing.lol.path`)? Is that right?