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!
Ok, great. Sometime soon I will implement those option-name changes and add jsDocs comments to finalize the pull request, unless other feedback pops up.