Reactivity: resources - Githubissues

[ ] finalize design
- [ ] depends on scheduler design for having clear answers to timing semantics (what behaviors can we expect when during which parts of the scheduling phases)
- [ ] See thread (and sub-threads) about official class-based option: https://discord.com/channels/480462759797063690/1161669019162648647/1202530820963958784

Blocks:

routing
- https://github.com/emberjs/tracking-polaris/issues/20
modifiers
- https://github.com/emberjs/tracking-polaris/issues/18
- https://github.com/emberjs/tracking-polaris/issues/12
services

the idea of resources is that they're the "destroyable" primitive, a more ergonomic way to do setOwner + associateDestroyableChild + registerDestructor (from @ember/destroyable) -- and would be an implementation detail for many higher-level things

open questions

[ ] property access vs "being a value"
- NVP: Why not both? there is no ergonomic difference between accessing properties on this vs accessing properties on anything else, imo. Accessing properties on this and making them "look like" the reactive thing (like @tracked) requires the usage of a decorator to hide the inner getter/setter.
[ ] should we base everything off ECMA resources?
- [ ] supporting these is a good idea
- NVP: but there is a current lack of convention around them (so I don't think they should be "the" resource implementation -- our resources could build on top of them though), (and Symbol.dispose isn't available yet). To use these, we'd have to require that folks define getters on their return object, like:
```
function Greet(name) {
return {
  get someValue() {
    return `hi, ${name}`;
  }
  [Symbol.dispose]() { /* ... */ }
}
}

<template>
{{Greet "NVP"}} -- can't work with ECMA resources, renders the object

we'd have to do this:
{{#let (Greet "NVP") as |x|}}
  {{x.someValue}}
{{/let}}
</template>
```
- [ ] do we want a consistent property-access only story around reactivity in general? (something @chancancode brought up, against using arrow functions for deferring reactivity instead of getters) NVP: I think we need to document how reactivity works in general (we haven't yet! :see_no_evil: ), and maybe this is a power-user technique, idk. Personally, I'm yet to be convinced on the importance of unifying on one-off classes / getters / properties instead of arrows. (this is slightly tangential to resources, but the patterns created by resource ergonomics so far have made us realize we have a lot of unanswered questions around reactivity in general)

emberjs / tracking-polaris

Reactivity: resources #31