Update generate:bundle for non-shared bundles and more

Hi guys!

If you're reading this, please try this out and offer any feedback! There are so many different cases, it will make @fabpot's life much much easier (and that's always good).

This replaces (adds to) @rafix's work on #299. The task ended up being a bit larger, because there are so many things we *could* change, and we need to communicate things well.

Fortunately, the changes here alter the generation process very little - most changes are to *how* we ask the questions. Here are the highlights:

* if a bundle is non-shared, we only ask for a bundle name, not a namespace
* removed "generate full directory structure" functionality entirely. This added only a few extra files, which I don't think add value.
* make `.yml` the service configuration format if you choose annotation format. If you're using annotation for routing, it's likely you're following the best practices are you might be surprised by XML :)
* many small output changes

BC breaks:

* I kept `BundleGenerator::generate` ONLY for BC, so it is *not* a BC break
* The `structure` option was removed
* You now get `services.yml` if you choose annotation as your format

In #299, we asked the question "should a non-shared bundle have a `Resources/` directory?". I think it should. Why? I think the `AppBundle` is special - it's the one bundle that's truly coupled to your kernel (e.g. `app/` directory), which is why it's ok to store the templates in `app/`. If we also stored templates from other bundles in `app/`, it gets a crowded. If you had a `DefaultController` in 2 bundles, their templates would "want" to occupy the same space (e.g. `app/Resources/views/default/*`).  So, I think it makes sense to have only one special bundle (per kernel) that you really *couple* to the kernel. *IF* you choose to add other bundles (which you don't need to do), I think you should organize them more along the lines of traditional bundle, at least for templates.

### TODOS

* [ ] If we agree with my above statements, then since the "non-shared" no longer has a DI directory, we'd need to add a something to the generation process to import the `services.*ml` file that's placed into the bundle.

* [ ] Can we break BC in the ways described above? Or do I need to re-add somethings?


What does everyone think? /cc @javiereguiluz 

Thanks!
Great! I would *love* to give all/many of the commands an overhaul, which could include other breaking changes like this. Anyways, I think we should merge this in then (when it's ready, there is still 1 more todo), and ideally I can do a few more PR's before we release that new version (I was thinking around Dec 1st along with 2.6).