Support scenario testing

[NullVoxPopuli]

Taken from https://github.com/html-next/ember-raf-scheduler/

[mansona]

very close! let me know if you have any questions about this review and we can hop on a quick call 👍

[mansona]

I understand why we're doing this because we need some ember-cli in the old versions but I don't think we benefit all that munch from having functions generate each of these scenarios. Can we just split it out to objects in the senarios array which will have a much clearer upgrade path for people used to ember-try?

[NullVoxPopuli]

why is that clearer?

with the functions, it's like... compatibility codified.
with "just objects", it applies every scenario has different compatibility requirements -- which isn't true

[mansona]

well it is true depending on how far back you go 🤔 as you go back in the versions you need to make more and more changes e.g. https://github.com/mansona/ember-cli-notifications/blob/main/test-app/config/ember-try.js

[NullVoxPopuli]

we should have some like.. shared database of these things somewhere -- centralized or something, in a library

[mansona]

yea I tried to add it to ember-try a while back but we're now off on a different path with @embroider/try

addressed comments

[NullVoxPopuli]

NOTE:
custom exportConditions won't work, because of this problem: https://stackblitz.com/edit/stackblitz-starters-4ydzmcht?description=Starter%20project%20for%20Node.js,%20a%20JavaScript%20runtime%20built%20on%20Chrome%27s%20V8%20JavaScript%20engine&file=pkg%2Fpackage.json,pkg%2Findex.js,package.json,index.js,pnpm-workspace.yaml,reversed.js&title=node.new%20Starter
which presents itself in vite build and vite dev

The options that were attempted for resolving self-imports:

• custom resolve alias (requires config in both vite and tsconfig)
• custom exportConditions - only works if you always specify extensions (no array / fallback lookups like in the stackblitz repro)
• ignoring self-imports and doing subpath imports (e.g.: PR Add package.json#imports #47)

We've discussed that for a docs/demo app, we'd still want the code to look like it would to a consumer. We can do that via custom resolves in vite and tsconfig, but we should make that a separate concern from this PR. Using subpath imports for testing is good, and is fine since testing can have a lot of not-so-common situations to begin with.

[lupestro]

Silly nit - node 18 still? I suppose this is going back a way, so maybe that makes sense.