LDAP util: When querying for schema, deal with servers that don't support listing all operational attributes (RFC 3673).

In order to correctly determine multivaluedness of attributes in LDAP, the schema must be considered. A typical query for the LDAP schema (once the schema DN is known) looks like this:

`ldapsearch -D "BIND_DN" -w "BIND_PW" -p 389 -h ldap.example.org -b "cn=schema" -s base "objectclass=*" "+"`

The attribute list placeholder `+` is needed because all attributes on schema enrties (type `subschema`) are so called **operational attributes**, which are *not* returned in a regular query - instead they must be explicitely requested. The `+` placeholder is shorthand for *"please return all operational attributes"*. This feature is specified in [RFC 3673](https://tools.ietf.org/html/rfc3673) and supported by most LDAP servers.

However, we recently had to find out that our [389 Directory Server](http://en.wikipedia.org/wiki/389_Directory_Server) does not support this feature. This means, instead of simply querying for all operational attributes, we need to explicitely list all the operational attributes we want to query for.

These are the attributes described in the [`subschema` object class (2.5.20.1)](http://www.alvestrand.no/objectid/2.5.20.1.html):

```
        MAY CONTAIN { 
                dITStructureRule |
                nameForms |
                dITContentRules |
                objectClasses |
                attributeTypes |
                matchingRules |
                matchingRuleUse 
        }
```

So the change in this PR makes the LDAP util
- first check whether the server supports RFC 3673 (querying for all operational attributes)
- and if not, queries for the explicit list of attributes defined above
- if the server does support RFC 3673, the existing query with the placeholder attributes `+` (and `*`) will be used

Long story short: this PR fixes #579

@phgross