considering removing locations

After some great feedback from Paul Irish and a lot of brainstorming, I think we could probably remove locations entirely. Locations' purpose are to allow consumers of a component to override aspects of the component when it's being used in a certain context. It's a common use case and csstyle needs to support it. Locations have a couple of problems however:
1. Because they use `id` they automatically override every part of component, including its options. So if you wanted to override the base style of a component using a location but leave it alone when it's using an option, you're out of luck.
2. People start using locations in places where they really should be using a component.
3. There are a lot of semantics to remember with components, parts, options, tweaks, & locations.

I think components themselves provide enough context:

``` scss
@include component(sidebar){
@include component(button){
// override some aspect of button when inside sidebar
}
}
```

And they do this with a single class name rather than an id. The only problem with this is that options and parts also only add a single class name. This would lead to load-order importance which is something csstyle is supposed to handle for you. One option would be to have csstyle add another class onto the parts & options selectors that get generated so that they are automatically more specific than the base styles applied to a component inside of another component.

I'm open to ideas and feedback before making a breaking change like this.

No files or tests are named. Start by reviewing the issue discussion and the existing component, part, option, tweak, and location behavior described there. Done requires an agreed direction on whether to remove locations and how selector specificity should work before implementation.

Written by the indexing model from the issue text.