Range handling

[jvillafanez]

From https://msdn.microsoft.com/en-us/library/aa367017(v=vs.85).aspx

Decided to go through the easy route and forward any attribute with a range.

Without this patch, if AD send any attribute with a range, the library will ignore it since it won't match what the user requested. This will lead to errors if the attribute has more values than the AD limit.
By forwarding these attributes the user will be able to handle it on his own, fetch the first bunch of results and ask for the next bunch.

As a short term solution this should be enough. There could be users who don't need to fetch all the values and will show whatever the server sends, and fetch more values on demand. Other users might need to fetch all values. There could be logic in the library to handle both scenarios, but this would be a long term solution.

[ChadSikorra]

Thanks for the PR. Sorry about the delayed response. I'll read through the range retrieval article this week. This looks like it'll probably be an OK workaround for the time being. I definitely want to find a way to support this properly. I was reading about this a while back but wasn't sure how to handle it then.

[ChadSikorra]

This is still on my radar. I plan on adding this for the next tagged release. I want to finish the work in #29 first, which will probably be a pretty sizeable commit. But I'd rather implement this with full support out of the gate instead of a work around I'll have to come back to.

[ChadSikorra]

The more I dig into this the more frustrating it becomes actually. This range handling isn't some AD specific format, it's actually defined in the LDAPv3 RFC as "Attribute Description" format. Basically you can send an attribute name and a "description" after a semicolon:

https://www.ietf.org/rfc/rfc2251.txt (Section 4.1.5)

Not only can you send it like that but LDAP can return it like that. But I never designed around this possibility. The LdapObject class expects just attribute names, not additional attribute descriptions appended to stuff. In retrospect I should have forced attributes into their own class, which would represent the: name, value(s), description. So now I'm not sure how to represent the returned attribute description from LDAP without some major changes, or unexpected attribute names.