Changes dummy app's detection and project.isModuleUnification()

[NullVoxPopuli]

from the quest issue: emberjs/ember.js#16373

specifically, this partially covers:

• Fix lib/models/project.js's isModuleUnification method to not only rely on presence of top level src as "the project is module unification format". Specifically, an addon may be in module unification format, but have its dummy app be in classic format.
• Ember CLI uses the presence of src/ to configure the return value of isModuleUnification(). This works well for apps and addons. The detection fails for a classic dummy app in a module unification addon, however. Although a dummy app may be in tests/dummy/app/ with no tests/dummy/src/ directory, the addon's root level src/ confuses our logic and the dummy app is incorrectly treated as a module unification app.

proposed scheme for multiple dummy apps:

• <root>/
  • tests/
    • dummy/
      • {app-name1}
        • a classic app
      • {app-name2}
        • a mu app

[NullVoxPopuli]

@ppcano @rwjblue @tomdale (@mixonic ?) Do we have a plan for this behavior? I was kinda just poking around with this, and don't know if there is a specific direction that we should go in?

[ppcano]

Added a test at #8322 -> MU addon can run a Classic dummy app.

The implementation was already done for this case (@mansona at #7485 ?)

Will multiple dummy apps be automatically supported? At first glance, it does not look like to be a common case.

[NullVoxPopuli]

@ppcano maybe not super long term, but I can see it being incredibly beneficial while we have a bunch of octane and classic apps out in the wild simultaneously. As an addon author, I'd want to be able to verify that if my addon is a classic addon, it'll work with both octane and classic apps, and if my addon is an octane addon, that'll it'll work with octane and classic apps.

The matrix of assurance that I want addon authors to be able to complete:

Addon ⇨ App ⇩	Octane	Classic
Octane	✔	✔
Classic	✘	✔

[NullVoxPopuli]

RIP MU