Typescript support for generator-angular

Hey Brian and other maintainers,

I wrapped up a bunch of changes to get typescript working out of the box with generator-angular. It's not feature complete, but there's definitely enough there to be very useful to anybody who wants to build an angular app in typescript. I'll be happy to continue porting other features that I have in my personal stack, but first wanted solid confirmation that there is interest in what I'm doing, so that my time is not wasted.

I tested backwards compatibility by diffing the directories resulting from running yo on my branch and on master. Also tested `grunt server` and `grunt server:dist` for both typescript and javascript versions. Let me know if you guys have some more systematic approach to regressions.

A bunch of notes about my changes are below. Obviously there are many ways of accomplishing the same goals in code; I tried to make sensible choices based on what I could deduce from the code. Happy to discuss and implement changes.

Also, there's a small changed necessary in generator-karma to get unit tests working. Submitting that shortly.

Cheers,

-anchann



* generate parts of Gruntfile.js, gitignore based on selected language
* set language in package.json for subgenerators to reference
  (for subsequent runs of the subgenerators)
* passing user choices to subgenerators (for the initial run
  of the subgenerators hooked from the main generator)
* reformatting of lodash conditionals that reads clearer yet still
  preserves whitespace
* overrideable configs templates (for things like backend URLs)
* template partials preloaded for dist
* controller and service generators

FUTURE WORK
* filter and directive generators
* ask user for top level module name
* revving of templates.js (with hopefully an elegant solution to the
  two pass problem)

NOTES

I could not find the intended way to pass user choices down to the
subgenerators that are hooked from the main generator. The pattern for
processing user choices seems to be setting the values on the generator
object itself, which are then made available in the template using,
presumably, a with block. To follow this pattern for subgenerators, I
needed a struct with user choices to be available in the constructor of
the subgenerator. Using the options-options during hook registration,
with a by-reference object in it that later gets populated with user
data, was the only way I could manage it.

It is conceivable that using this.env.options is the idiomatic way, and
it has one benefit of not differentiating where the choice comes from,
question-answer session with the user, or cli arguments. The problem
with it, though, is that it completely obscures data flow through the
program, and makes it impossible to trace where values are coming from.
I am a strong proponent of explicit data flow.

Also reformatted _bower.json so that the conditional expression appears
on the same line as what is being conditionaly included, while still
preserving the white space properties (i.e. no empty newlines are added
for false conditions).