updateFastBootManifest isn't invoked for nested addons #597
Description
When ember-fetch is only present in a project as a transitive dependency, it breaks in FastBoot because its updateFastBootManifest hook is never invoked. This has resulted in issues for a number of addons that depend on ember-fetch, and in the wild, some addons have started installing it in the host project in their default blueprint to work around the problem.
I chatted with @kratiahuja in Slack a bit, and it sounds like it would be reasonable to start invoking that hook for nested addons. This would make it so that it doesn't matter whether an addon is a direct or indirect dependency, which is consistent with how addon-introduced content generally works otherwise, but it also raises a question: what (if anything) should ember-cli-fastboot do about the possibility of duplicate assets winding up in the manifest?
One option would be to say addons need to guard against this themselves, e.g. by checking whether an asset they want to include is already present, but that seems like sort of a footgun given that it's something that every implementation of the hook would likely need to remember to do.
Alternatively, ember-cli-fastboot could dedupe by path in the vendorFiles and appFiles arrays, in a similar way to how ember-cli dedupes app.import()ed files. That raises some of the same questions about which duplicate(s) get removed, since order could matter in those arrays.
I'm happy to open a PR, assuming there's consensus on an approach for handling (or not handling) the duplication question.