Update: Add exception options to space-in-parens (refs #1368)

These changes allow the user to set an additional options object for `space-in-parens` to allow for exceptions **when `always` is `true`** --- inspired by the exceptions available for `space-in-brackets`. (It should have no affect if `never` is true`.)

```js
// example exceptions object
{
  brace: true, // expect no space between parens and braces, e.g. ({ a: b }) instead of ( { a: b } )
  brackets: true, // expect no space between parens and brackets, e.g. ([ a, b ]) instead of ( [ a, b ] )
  parens: true, // expect no space between parens and other parens, e.g. (( 1 + 2 )) instead of ( ( 1 + 2 ) )
  noEmpty: true // expect no space within empty parens, e.g. foo() instead of foo( )
}
```

This means that `always` might deliver either of the available messages -- `"There must be a space inside this paren."` or `"There should be no spaces inside this paren."`. If, for instance, a `({` is found and the `brace` exception is `false`, you will get the "... *must* be a space ..." message; but if `brace` is `true` and a `( {` is found, you will get the "... should be *no* spaces ..." message.

Basically, the added code is just about building more complicated regular expressions.

The discussion in #1368, and an open question for debate, is whether this rule should (or *can*) be refactored to use parsing instead of just regular expressions. If parsing were able to be used, we could allow for some options that I don't think this regexp method can't really address, e.g.:
- Only disallow spaces between braces or brackets and parens when it involves objects or arrays that are *lone* arguments (as the jQuery style guide specifies, for example)
- Don't allow spaces around `function() {}` arguments -- so `foo(function(){})` instead of `foo( function(){} )`(again in jQuery style guide)
Maybe those are edge-cases not important enough to address ... or maybe the functionality would be too difficult to write. Just bringing it up.

I didn't write any documentation because I'm looking for the feedback first. Thanks!
I like the `exceptions: []` pattern, too.

My only reservation about the JSCS style is that it forces users to specify *both* sides of the punctuation rather than just a single value, when I think it's probably safe to presume that if you want to allow `({` you also want to allow `})` (right ?). (Though there's always some value in being explicit.) Nevertheless, if there's concern about ambiguity with terms like `braces` and `brackets`, then there's probably no better way to resolve it than typing the exact character you mean. What about allowing for two possibilities:

- `exceptions: ["{", "}", "[", "]"]`
- or `exceptions: ["{}", "[]"]` (single value for each punctuation mark)

--- do you think that works?

> The exceptions need to work for both the always and never conditions, as well.

I guess I missed that never+exceptions was a possibility for `spaces-in-brackets` because all of the examples of exceptions use `always`. I'll work on building that in, as well.