unify count filters and introduce display name attribute detection

This fixes https://github.com/owncloud/core/issues/11328 and introduces some bigger changes.

1. we introduce the detection of the display name attribute, because on not so few LDAP setups "displayname" is not present. The detectors first checks whether there are entries having "displayname" according to the current user filter. If not it checks "cn". "cn", short for "common name" should be available everywhere. If necessary we can extend it with "uid" and "samaccountname" although those are not meant to be displayed to users. This also ensures that users will be able to log in since a present display name is a condition.

2. The wizard and the user backend created different filters for counting users by there own. They have been consolidated in Access and are used by both. The created filter also takes display name into account, and the number of LDAP users in user managament and wizard is now the same.

3. We now have three detectors, one for the email attribute and one for the group member association was already there. They were called in several places, now I cleaned it up so that they are always one run just before a count action. For setups using the totally assisted mode it means that the detectors will run anyway. They will also run in experienced mode, when "test filter" is clicked. To make sure they run even if the button is not clicked, we watch the state and run them ONCE when the user respectively group tab is left. All in all that saves some initiated and cancelled calls.

4. The wizard backend was improved in a way that for certain count operations a flag can be set limits the query to just 1. We need this to verifiy whether an attribute does still work with the current filter (email, displayname) where it is not necessary to count every single object, one presence is enough. This is done to avoid another full detection run. Also, when determining the display name this limit is used. I.e. those actions are faster now. It incorporates a fix where the limit was not respected properly in the count method (no side effects as it was not used anywhere else).

5. it incorporates a fix where the email attribute was detected and presented in the user interface, but not saved.

While testing i have seen some disbehaviour in the wizard which however is also present in master. Those I will investigated independtly from this PR.

Call for comments, tests and reviews @craigpg @jnfrmarks @PVince81 @Xenopathic @butonic 

Detectors do not depend on experienced mode or not, they are the same. Only in the later case it is not guaranteed that they are triggered, because this is only on demand, but having the detectors running is important for a proper configuration.