Fix check in dependencySatisfies in monorepo

[SergeAstapov]

Came across exact same issue described in #1051 while working on porting ember-animated to V2 addon and all scenarios for versions 3.20 and below failed.

Note that I've ensured all @embroider/* packages are latest (via deps updates or resolutions).

Situation is exactly what was described in #1051:
ember-animated is a monorepo with docs app running on 3.28 and when running ember-try scenario for 3.20, this check in @embroider/util returns true, as both @embroider/util and ember-source@4.1 are in the hoisted main node_modules, while the test-app in question has its own ember-source@3.20 in its local node_modules.

I'm not sure this is right way to fix the issue nor how to properly test it with current test harness setup:

using appRoot totally makes sense for dependencySatisfies macro (as we need to rely on the host app deps) but may not be the right choice when we invoke packageCache.resolve on this line.

@ef4 would love your input on this.

cc @simonihmig as original reporter of #1051, not sure if issue still persists for you.

[ef4]

dependencySatisfies is truthfully reporting a real problem here, which is that if ember-animated tries to directly import anything from ember-source it's going to get the wrong copy. This is the fault of yarn (and NPM, which yarn is faithfully copying). It's just very incorrect that yarn violates the declared peer dependencies like this.

Three ideas for paths forward:

1. Let's try pnpm. I've heard multiple reports of people happily using it in ember monorepos. I think it gets the peer dependencies correct. ember-try has support for it already.

2. It's also possible to solve this using scenario-tester as we do in the embroider and ember-auto-import monorepos. This doesn't have the ease-of-use that ember-try has, but it gives you a lot of control.

3. I hesitate to add this option, but I did consider it and will share it for completeness. We could add a special-case macro just for testing the ember version like emberVersionSatisfies('>=3.25'). This would often do what people want, but at the cost of kicking the underlying problem down the road.

[SergeAstapov]

We were able to find a workaround for this problem by using pnpm with dependenciesMeta.*.injected option:

in ember-animated/test-app/package.json added such config:

"dependenciesMeta": {
  "ember-animated": {
    "injected": true
  }
}

This ensures proper peer dependencies resolution in the test app.

The downsides of this approach can be found in this discussion.