Add support for specifying a path for the generate command

[NullVoxPopuli]

This is needed for this project:

• https://github.com/NullVoxPopuli/ember-codemod-blueprint

Which has these remaining TODOs before the idea can even work

• add an API to allow accessing what files are generated in afterInstall (not the focus of this PR)
• add a path in place of the blueprint name, similar to how new can use a path to a local blueprint,
  rather than rely on the name resolution system currently in place.
  this is useful, for wanting to chain blueprint executions, as is the focus of ember-codemod-blueprint
  (what this PR is focused on)

I'm open to advice on approach here, but those two bullets are what I need to be able to build more straightforward and extensible blueprint in user-space.

I'm kind of thinking about blueprints being like this at a high level (after the above work):

generateBaseBlueprint('ember-source/blueprints/component')
 |> renameToTypeScript
 |> addTypeArgument
 |> etc

actual api in https://github.com/NullVoxPopuli/ember-codemod-blueprint -- main difference is no pipes, and you'd want to work with specific file paths, rather than whatever the blueprint output is.
So a snippet from ember-codemod-blueprint,

module.exports = codemodBlueprint({
  upstream: 'ember-source/blueprints/component',
 
  transform(options, helpers) {
    let { transformScript, transformTemplate } = helpers;
    let { generatedFiles } = options;

    for (let fileInfo of generatedFiles) {
      
      if (fileInfo.name.includes('app/components') && fileInfo.name.endsWith('.js')) {
        await transformScript(
          scriptPath, 
          transformA, 
          transformB, 
          transformC
       );
     }
     // etc, and more transforms for the other files
    }
});

This approach should work for app-generation as well, but the transform hook may be much bigger, depending on how different your team's default app is from the base blueprint

[mehulkar]

Some high level feedback: instead of a second arg, you could use the same one? ember g named-blueprint and ember g path/to/blueprint could be nicer

[NullVoxPopuli]

Just tried this in a monorepo, and it was succesful:

❯ ember g ../../../node_modules/ember-source/blueprints/component my-component-via-path
installing component
  create addon/components/my-component-via-path/index.hbs
  skip addon/components/my-component-via-path/index.js
  tip to add a class, run `ember generate component-class my-component-via-path`
installing component-test
  create tests/integration/components/my-component-via-path-test.js
installing component-addon
  create app/components/my-component-via-path.js
  
❯  ember d ../../../node_modules/ember-source/blueprints/component my-component-via-path
uninstalling component
  remove addon/components/my-component-via-path/index.hbs
uninstalling component-test
  remove tests/integration/components/my-component-via-path-test.js
uninstalling component-addon
  remove app/components/my-component-via-path.js

[NullVoxPopuli]

Related: emberjs/rfcs#699

[lifeart]

could we add check for relative/absolute paths, is cwd = curren project dir?

[ef4]

This seems OK to land, we just need to rebase and make sure tests still pass.