Feature/optional apollo

[JohnRodney]

@Chun-Yang Hey can you review this code when you get a chance and give me an opinion? Once you are ok with it I can close the PR and do a auto tag that you like 😄

[Chun-Yang]

The ci is broken it seems. Could you fix the ci?

[coveralls]

Coverage decreased (-1.6%) to 92.857% when pulling 2c4174255aa77b40849f163b260d96050f70a5f8 on feature/optionalApollo into 367383a4f5934dbee1806fd0ed9f1bb2fc29c68f on master.

[JohnRodney]

@Chun-Yang Hey fixed the CI and adjusted the options to --apollo. Do you think in the long run we could think of a way to allow these plugins to be external in order to keep them from coupling / cluttering our stack?

I think it would be nice in the long run to be able to just add remove things as plugins from this stack, but short of adjusting code to add the options parameter I'm not sure how we could do that, unless we have a optional .json object to describe the bahavior as a whole.

  plugins: {
    args: '-a, --apollo', /* options it registers as */
    filepath: '../templates/apollo',   /* relative to the entry point */
    entryPoint: 'www.github.com/somegiturl.git', /* the bin file or entry point of the plugin */
    hooks: ['afterCreate', 'afterUpdate'] /* the types of hooks to register these options for */
  }

Maybe something like this could be added into the system so that apollo, webpack, ect can be added to the bootstrap without affecting the root stanza repository.

Also I think the method I used here for copying the template folder works for one plugin but what if 3 plugins want access to the same file. The copy will replace I'm guessing or fail. While maybe it should be merging and then somehow sorting the lines so that all imports end up on top ect.

Let me know when you have some more time to discuss this.