Add extensibleMatch filter support, fix multi-byte filters

[liggitt]

Fixes #28

• adds support for extensible match sequence (both in CompileFilter and DecompileFilter)
• switched the filter parse to a simple state machine, rather than keying off whether the packet was nil, since attribute parsing could transition to extension matching rule or filter value
• simplified "nextRune" handling to check "currentRune" for performance, then do simple HasPrefix checks. Needed to check variable length prefixes like ":dn:=", ":dn:", etc.
• Fixed encoding of substring match strings and added tests.

Fixes #39

• In cases where we got non-escaped content in the condition, we were iterating on bytes, not runes
• Fixed incorrect multi-byte testcases, and verified byte output matches actual bytes for those characters

[liggitt]

refactored so that substring and extensible match filters can reuse this

[liggitt]

@johnweldon please take a look

[liggitt]

Tested against a live LDAP server with the following extensions:

    ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Search filters were accepted as valid, and behavior indicated extension was passed successfully

// case-sensitive match, 1 result returned
(uid:1.3.6.1.4.1.1466.109.114.1:=myuid)

// no match, zero results returned
(uid:1.3.6.1.4.1.1466.109.114.1:=MYUID)

// case-insensitive match, 1 result returned
(uid:1.3.6.1.4.1.1466.109.114.2:=MYUID)

[liggitt]

in case you want to verify the old bytes were wrong, and the new bytes are right: http://play.golang.org/p/GeNmpuSEs7

[stevekuznetsov]

What behavior will this have for nested groups?

[liggitt]

It lets you tell the AD server you want it to flatten membership for you, rather than recursing yourself

[johnweldon]

LGTM,