`updateFastBootManifest` isn't invoked for nested addons

When `ember-fetch` is only present in a project as a transitive dependency, [it breaks in FastBoot](https://github.com/ember-cli/ember-fetch/issues/98) 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](https://github.com/bgentry/ember-apollo-client/blob/73c259e476542c9c317c3ff64ae1f48fe3a67c1a/blueprints/ember-apollo-client/index.js#L12-L14) [addons](https://github.com/tchak/ember-fetch-adapter/blob/d642652f18276e5552304255014691483ecdfb56/blueprints/ember-fetch-adapter/index.js#L10-L12) 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](https://github.com/ember-cli/ember-cli/pull/6603#issuecomment-268930267) 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.