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.
I'd implement separate classes `Whitelist` and `Blacklist` who share their functionality in a common `Zebra\AbstractList` ;-) with `filter()` calling an abstract method which is implemented by `Zebra\Whitelist` and `Zebra\Blacklist` appropriately -> IOC.
I saw your PR description, but I think, a clean architectural approach should be favoured over one or two less classes.