ldap discover username/password fix, paging and dn check

Relating to http://trac.openmicroscopy.org.uk/ome/ticket/11711

## Username/Password for bind
discover currently doesn't actually ever use the ldap username and password so it can't bind the connection. Is it even possible to have a passwordless ldap server connection? If so it might be worth testing that those still work if someone has such a setup with passwordless access?

## Paging
Secondly, on a production LDAP system there are often more users than can be returned in a single query due to LDAP server enforced limits. I've added paging which will do 1000 (or less if the server reports it's sizeLimit is less) at a time.

I will pep8 format the code once I fix pylinter in my Sublime.

## DN Case Sensetivity

When a new user connects for the first time to OMERO something like this is set in the database:
```
cn=user1234,ou=Some Group,ou=Users - Lab,dc=bioch,dc=ox,dc=ac,dc=uk
```
This is correct in as far as when the user then tries to log in later, it validates. However, discover flags up all of the entries in the database as incorrect:

```
Found different DN for user1234: cn=user1234,ou=Some Group,ou=Users - Lab,dc=bioch,dc=ox,dc=ac,dc=uk
dn (in OMERO): cn=user1234,ou=Some Group,ou=Users - Lab,dc=bioch,dc=ox,dc=ac,dc=uk
dn (in LDAP): CN=user1234,OU=Some Group,OU=Users - Lab,DC=bioch,DC=ox,DC=ac,DC=uk
```

This is probably just because different LDAP connectors treat case differently. If you change the entry in the dn field of the password table to:

```
CN=user1234,OU=Some Group,OU=Users - Lab,DC=bioch,DC=ox,DC=ac,DC=uk
```

then the user can not login as the DN is not valid:

```
2013-11-17 02:11:39,305 ERROR [services.blitz.fire.PermissionsVerifierI] (.Server-52) Exception thrown while checking password for:user1234
ome.conditions.ValidationException: DNs don't match: 'CN=user1234,OU=Some Group,OU=Users - Lab,DC=bioch,DC=ox,DC=ac,DC=uk' and 'cn=user1234,ou=Some Group,ou=Users - Lab,dc=bioch,dc=ox,dc=ac,dc=uk'
```

I can very easily fix this test in discover by doing a case insensitive comparison instead of using equivalence. 

### Finally my point:
It might also make sense to make the PermissionVerifier not care about this case difference either given that LDAP is nearly (except for passwords and apparently some really obscure attributes) case insensitive.