[WIP] Detection of existent codestyle

This is a **WIP** Pull Request for #30. It would be updated with a new code, resolving the issues below.

As I'm a bad programmer, so please look at this code with a serious face and either point me all the bad things I've done (so I could go and fix them), or treat it as a proof-of-concept-prototype, which you can take and rewrite from scratch :)

What is done now: there is a flag `._detect` that tells processing functions not to rewrite the codestyle, but instead only read and populate the `._detected` object. Then there is a `.detect()` function that sets this flag and populates the `._detected` objects with the properties we want to detect. In future it would take an array of the options we want to detect. And finally, if the flag is set, the processing functions should return the object with detected options. Right now only `.processString` is covered, others would be done later. And then every option can have its `detect` method, that should return the found codestyle for the node. I've tried to reuse the existent code as much as I could, but if there any things that could be done in a more optimal way — tell me (or send a PR for my PR's branch and I'll merge it into it).

## Major features:

- [ ] Detection — CSSComb.js should have a way to parse a CSS file and return an object with detected options.

- [ ] Normalize — CSSComb.js should have a way to use its detection to normalize existent files. It should take files, detect the properties in them and then use the detected code style to normalize all the stuff. Question: should we have two possible options for normalize feature — a) we should either normalize files independently, so each file's code style would be normalized with itself, or b) we could sum all the codestyles in the given files, so it would be averaged to the whole input.

- [ ] Read settings from `.css` file — CSSComb.js should take `.css` file as a `-c, --config [path]`, in that case it should detect the used code style there and use it as a template. And/or, instead of using `.css` file, we could have a `template` option in `.csscomb.json`, which would point to this template file, this way we could then merge the detected options with the ones we have in the `.csscomb.json`.

- [ ] Readme for all the stuff above :)

## Options to do:

- [ ] `remove-empty-rulesets` — *how should we detect it? If there are no empty rulesets found in a template, then it's `true` and `false` otherwise?*
- [x] `always-semicolon`
- [ ] `color-case`
- [ ] `color-shorthand`
- [ ] `element-case`
- [ ] `leading-zero`
- [ ] `strip-spaces`
- [ ] `eof-newline`
- [ ] `stick-brace`
- [ ] `colon-space`
- [ ] `combinator-space`
- [ ] `rule-indent`
- [ ] `block-indent`
- [ ] `unitless-zero`
- [ ] `sort-order` — *ah, that should be really non-trivial to detect!*