Add pod blueprint generators

Introduces the option for using a pod structure when generating a blueprint by passing the `--pod` option, as described in #1619 (This PR is a cleaned up version of #1879)
```javascript
ember g resource taco --pod
/*
 would generate-
 app/pods/taco/route.js
 app/pods/taco/template.hbs
 tests/unit/routes/taco-test.js
*/
```
The pod option uses the original blueprint, but transforms the tokens used for the `mapFile` method. Previously this was limited to `__name__`, which was used throughout the default blueprint files folder. There are two additional default tokens required for blueprints that support pod structure: `__path__` and `__test__`. These three tokens allow quite a bit of flexibility, including support for nested pod generation:
```javascript
ember g resource taco/cheese --pod
/* 
 would generate-
 app/pods/taco/cheese/route.js
 app/pods/taco/cheese/template.hbs
 tests/unit/routes/taco/cheese-test.js
*/
```
The tokens are used to generate a fileMap based on the structure defined. If `--structure` is not passed, the default structure will be used. The `__test__` token is necessary because the name token changes per structure:
```javascript
// pod
fileMap: {
  __name__: 'controller',
  __path__: 'pods/taco',
  __test__: 'taco'
}
// default
fileMap: {
  __name__: 'taco',
  __path__: 'controllers',
  __test__: 'taco'
}
```

The fileMap (which is defined on the locals), is used for the `mapFile` method, which writes out all the paths for the files to be generated when the blueprint is installed. MapFile simply loops through the defined tokens and replaces the token instances in files with the defined values.
```javascript
Blueprint.prototype.mapFile = function(file, locals) {
  var pattern, i;
  var fileMap = locals.fileMap || {__name__: locals.dasherizedModuleName};
  file = Blueprint.renamedFiles[file] || file;
  for(i in fileMap){
    pattern = new RegExp(i, 'g');
    file = file.replace(pattern, fileMap[i]);
  }
  return file;
};
```
This PR also introduces the ability to define custom tokens to be used in the files to be installed. This is achieved through a new blueprint hook called `fileMapTokens`. The hook will be processed along with the locals, and add or override any tokens the author wishes. To add a token, the author must add the hook method to their blueprint index.js, defining each token, and a function that resolves the token value. See route and component blueprints for an example.
```javascript
module.exports = {
  fileMapTokens: function() {
    return {
      __token__: function(options) {
          // this could be a series of checks and returns
          // as long as it returns a value
          return 'value';
      }
    };
  },
```
After some thought, I actually think this probably isn't necessary, as it is entirely acceptable to generate a pod without a podModulePrefix present. We could just have a warning instead, and put it behind the same flag for the other warnings so it isn't as noisy unless the user wants that.