Describe business value of features in specs

@charlierudolph This is a preview of what I'm planning to do with all specs. Wanted to get your feedback before I invest a lot of time into this.

This helps understand WHY the feature exists. The steps then explain HOW the feature works.
This also helps formulate the value of Git Town to teams better.
This is a feature, not an implementation error. This behavior wasn't specified before. We identified this missing feature from user feedback. 

These user stories describe why the feature exists in the first place. If a feature doesn't provide value to the user, it should not be in the product. So let's find out the value that this feature provides by asking the 5 why's. If we can't find or articulate value, we should take the feature out.

Why is it important that I am told that the branch name is taken? So that I understand why the command aborts. Why should the command abort when I try to extract into an existing feature branch? Because that branch already likely contains another feature, and we don't want to mix features in feature branches. Why do we prevent mixing features in branches? So that feature branches always only contain one feature. Why do we want feature branches to only have one feature? So that reviewing them is easy. Why do we want code reviews to be easy? So that the team is more productive. "Productivity" is an end-user value. Easy code reviews also. Making sure the branches only contain one feature creates that. That's why this feature exists.