graph/ldap: Use "groupOfEntries" objectClass for writeable LDAP backend

For groups created via the graph API we currently rely on the `groupOfName` Objectclass standardized in RFC4519 (https://datatracker.ietf.org/doc/html/rfc4519#section-3.5). This objectclass has a fundamental issue as it requires the `member` attribute to be present, i.e. it does not allow to create a group without members. As a workaround we currently add an empty string (`""`) as a value to the member attribute when creating a group or when removing the last real member. As outlined in #6170 this causes some race conditions, when multiple request to remove (or add) members are issued in parallel. We added workarounds (#6214) to handle this conditions more graceful. However we could largely simplify our code by switching to an objectclass that does not have the above issues.

"groupOfEntries" basically provides that. The main drawback of it, is that it is not fully standardized. It's only specified in IETF internet draft (https://datatracker.ietf.org/doc/html/draft-findlay-ldap-groupofentries-00). However, for the case where we allow the graph API to write to the LDAP server we need to have full control over the schema that is deployed there. So it would not be a big issue if we just used "groupOfEntries" in that case. (For the read-only LDAP support we can still continue to support groupOfNames, it's just a matter of configuration).

We'd need to provide some form of migration though to move existing deployments with writeable LDAP backends to "groupOfEntries".