User stories for git-extract

@charlierudolph @allewun adding user stories that describe end-user value
Hey, hate is a pretty strong negative emotion. You have mentioned that several times now, and I hear you. Actually, now that I look at this again, with some distance after a week in Newark, I'm also not too keen on all the repetition here. Its also hard to get an overview of the value of each features this way. Let's think about how we can dry this up, make not suck, and be useful instead. 

* `xxx_without_open_changes` almost always has the same user value (UV) as  `xxx_with_open_changes`. Let's leave the UV only in one of those files, and replace it in the others with a reference ("`(see xxx_with_open_changes)`")

  I vote for leaving the UV spec in the alphabetically first file (`xxx_with_open_changes`), and removing it from the remaining files (`xxx_without_open_changes`).

* There is also a lot of repetition coming from having to re-motivate the whole feature even in simple feature enhancements or specs for edge cases. Let's change it so that only the "main feature specs" (i.e. the one that describe the fundamental basic use cases for a feature) motivate the feature and describe the end user value. 

  Feature enhancements (like "hey, it should also works with multiple files" or "it should also work on the main branch") can assume that the UV of features is already known. They merely have to motivate the enhancement by describing how it makes the main feature more useful.

  Edge case specs (those that specify behavior in error situations) are fine just describing how the respective edge case is handled properly and safely.

* to make the separation between main feature specs, enhancements, and edge cases more clear, we could re-arrange the file structure for specs:
    * the top-level folders for the respective feature spec (e.g. `/features/git-extract`) only contains the main specs. 
    * refinement specs live in a subfolder "refinements" (e.g. `/features/git-extract/refinements`)
    * edge case specs live in a subfolder "edge-cases" (e.g. `/features/git-extract/edge-cases`)

What do you think about this, @charlierudolph and @allewun? Do you have more ideas? I think embedding the UV in specs is powerful. It provides more context around what a feature tries to achieve, and why its there. This helps developers make sure its useful, and come up with meaningful solutions for all the detail questions that cannot be specified at this level of granularity. 

This is a great chance to develop this technique so that it can benefit other projects as well. Lets be creative!  :)