New Whitelist / Blacklist Filter

This new filter will behave either as a blacklist or a whitelist. If the value being filtered exists in the list of known values, the filter will return the value if its a whitelist or `null` if its a blacklist. The opposite will happen if value is not in the list.

### Whitelist
```php
$whitelist = new \Zend\Filter\Whitelist(array(
    'list' => array('allowed-1', 'allowed-2')
));
echo $whitelist->filter('allowed-2');   // => 'allowed-2'
echo $whitelist->filter('not-allowed'); // => null
```

### Blacklist
```php
$blacklist = new \Zend\Filter\Whitelist(array(
    'type' => 'blacklist', // optional, default is 'whitelist'
    'list' => array('not-allowed-1', 'not-allowed-2')
));
echo $blacklist->filter('allowed');        // => 'allowed'
echo $blacklist->filter('not-allowed-2');  // => null
```

### Notes  

1. Maybe calling the filter class `Whitelist` might be counter-intuitive if the desired behavior is that of a blacklist. But I couldn't think of a better way to name the filter, so I'm open to suggestions:
    * Something like "AllowedList" would just be a synonym of "whitelist". 
    * "List" would just be too vague.
    * Separate filter classes seemed overkill.
2. I decided to allow only one type of configuration in the constructor (by array of options) just to keep it simple. If you'd like to allow for a more dynamic constructor (like a few other filters do) let me know.
3. Not sure what commit edbc12b is doing in this PR. Looks like its in `master` but not in `develop`.

See #6960 for more info.
They actually share the exact same logic but the end result is the opposite. How about I make `Blacklist` extend `Whitelist` and in the `filter()` function:
```php
class Blacklist extends Whitelist {

    public function filter($value) {
        return ! parent::filter($value); // Blacklist will return the opposite of Whitelist
    }

}
```
Or would that couple them too tightly?