Prepare for Ember adoption

[chriskrycho]

Tracking issue for readying this package to be the "polyfill" for emberjs/rfcs#812 – we will keep this updated as that evolves!

• delete doesn't trigger recomputation #27
• update the constructors to match those for the types they represent? (ongoing discussion with Framework team)
  • Decide on design for (and implement?) TrackedArray constructor #317
  • Decide on design for (and implement?) TrackedObject constructor #318
• Integrate tracked-maps-and-sets directly into the addon #320
• Convert this to an Embroider v2 addon #327

[NullVoxPopuli]

cross-posting from here: starbeamjs/starbeam#89

but, imo (ofc, but strong feelings), the current TrackedArray implementation needs some performance improvements before being adopted by Ember.
it's already implemented in ember-data, here: https://github.com/emberjs/data/blob/main/packages/store/src/-private/record-arrays/identifier-array.ts

Also, we probably also need proper storage primitives, because all the storage primitives (right now) greatly thrash memory and cpu compared to if the storage primitives were non-polyfilled.
(build on top of tracked requires decorator + class + instance on top of the native tracked implementation), and doing that for every tracked value is a lot.