allow templates for new apps/blades/libraries to be pluggable to improve scaffolding options

[andy-berry-dev]

Create a mechanism (similar to http://yeoman.io/) so devs can write their own templates and users can select which template to use for a new app/blade etc

For the first pass we don't need to create anything too clever. Pointing at a template directory or URL should be fine. The logic capabilities of the template definitions should not be the subject of discussion for this first pass.

Maybe a full template is just a template app with all supported Asset Containers defined and each command (create-app, create-bladeset, create-blade, create-library) just uses the appropriate one. I believe we already have a mechanism similar to this anyway.

[leggetter]

Templates are also discussed here #3

Yeoman generators are used for scaffolding applications. You might - for instances - create a BRJS Yeoman generator that would understand BRJS templates, but also BRJS application structure.

In our case we just want templates as the application structure is defined by the BRJS model.

[andy-berry-dev]

After a design discussion with @dchambers @james-shaw-turner and @ioanalianabalas we've decided on the following:

• create-app, create-bladeset, create-blade & create-library will all accept an optionaly --template=<template> arg that specifies the template to use
• if the --template arg isnt provided the default will be used
• all templates will live in conf/templates and templates will be named <template-name>-<asset-container-type> - e.g. angular-blade, angular-bladeset etc.
• the template name for the 'default' template will be ommited

@leggetter has suggested some changes to this plan (comments welcome):

• templates should be in a sub directory with the template name. e.g. /conf/templates/angular/blade, /conf/templates/angular/bladeset etc.
• Using templates from a GitHub repo URL/path should also be possible - e.g. --template=<repo-url>
• as a 'would like to have' it would be nice to have an entire app structure as a template rather than having to break it down into it's constituent parts (this is probably not likely to happen in the near future)

Unless anyone has any objections it would seem sensible to include the first 2 of @leggetter's suggestions in the initial plan for template support.