Support multiple regex matches

[jplitza]

The current implementation uses re.match and hence only replaces groups in the first match of the regexp. This PR changes that behavior to instead use re.finditer to replace all groups in all matches.

This actually makes it possible/easier to match all possible IP addresses (without depending on their surrounding context) by a user-supplied regexp. See the added testcase for an example regex that matches much more than IP addresses, but in particular also IP addresses (which is unproblematic if replace == None since the real verification takes place using the ipaddress module).

Also, the access log line in my newly added test case, with the [ip:1.2.3.4] at the end, actually appeared in an access log, with different IP addresses in the beginning and at the end!

This PR also closes #61 by using match group's indices for the replacement instead of str.replace

N.B.: I haven't verified that all newly used methods and features (in particular re.Match.start(), re.Match.end() and enumerate(start=1)) are available in all supported Python versions.

N.B.: I haven't evaluated the performance impact of this change.

(Rant: The choice to replace only groups instead of using look-aheads and look-behinds in the pattern made this change quite a bit more cumbersome, but I'm 10 days too late to change that I guess)

[jplitza]

After rolling this out to multiple servers, I learned two things:

• The initial version wasn't compatible with Python 3.5 (installed on Ubuntu 16.04). Should be fixed now.

• Using a regex that matches too broadly not only causes heaps of warnings ("this doesn't look like an IPv4 or IPv6 address"), but also degrades performance. So I'm now using this quite specific regex for our deployment:

    --regex '(?a)((?:(?:25[0-5]|(?:2[0-4]|1[0-9]|[1-9])?[0-9])\.){3}(?:25[0-5]|(?:2[0-4]|1[0-9]|[1-9])?[0-9])|(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|:(?:(?::[0-9a-fA-F]{1,4}){1,6})|[0-9a-fA-F]{1,4}:(?:(?::[0-9a-fA-F]{1,4}){1,5})|(?:[0-9a-fA-F]{1,4}:){1,2}(?::[0-9a-fA-F]{1,4}){1,4}|(?:[0-9a-fA-F]{1,4}:){1,3}(?::[0-9a-fA-F]{1,4}){1,3}|(?:[0-9a-fA-F]{1,4}:){1,4}(?::[0-9a-fA-F]{1,4}){1,2}|(?:[0-9a-fA-F]{1,4}:){1,5}(?::[0-9a-fA-F]{1,4})|(?:[0-9a-fA-F]{1,4}:){1,7}:)(?![\.:]?[0-9a-fA-F])'
  

  This expression is based on this and this, with comments of the latter and some more modifications applied, and reduced to what is actually found in logs. This now processes approx. 400k lines per minute on my test machine, vs. 100k with the too broad match.

  Maybe this could even become the default if --regex is passed without a custom regex.