Airlift updatePathsForAddon from the blueprints package

[dfreeman]

It turns out the default blueprint relied on the fact that we were adding ember-cli-typescript-blueprints to import an updatePathsForAddon utility function. Since that's no longer a safe assumption, I've just airlifted that function directly into this codebase.

I also updated a couple places in the docs that assumed the presence of ember-cli-typescript-blueprints by default.

[chriskrycho]

Huh, is this a standard Yarn pattern for self-resolution? I hadn't seen it before.

On reading the lock file changes, how does this impact consumers (if at all)?

[dfreeman]

Huh, is this a standard Yarn pattern for self-resolution?

I'm not sure if it's "standard" but it's definitely one I've used in a few places. In principle it could blow up on us in a future where we make big breaking changes here and our dependencies that rely on ember-cli-typescript aren't ready for that but are having it forced on them anyway. Since I don't think we're super likely to be making any changes like that, though... ¯\_(ツ)_/¯

On reading the lock file changes, how does this impact consumers (if at all)?

I don't think it should impact consumers at all, since resolutions only apply in your project's own package.json, not your dependencies'.