Improve WAC groups management API

Right now we use a custom API to create groups (we must POST to the `/_groups` path)

However WAC groups can be created like any other resources. The only requirement in the [specs](http://solid.github.io/web-access-control-spec/#access-subjects) is:

> The acl:agentGroup predicate denotes a [group of agents](http://solid.github.io/web-access-control-spec/#agent-group) being given the access permission. The object of an `acl:agentGroup` statement is an instance of `vcard:Group`, where the members of the group are specified with the `vcard:hasMember` predicate.

It is up to the group owner to ensure that it is protected correctly.

WAC groups should be on the own named graphs, like any other LDP resource. It will be possible once we [get rid of the Fuseki WAC extension](https://github.com/assemblee-virtuelle/semapps/issues/1189).

They will probably be put in a `/vcard/group` container... which is where contacts groups are also located. It doesn't seem to be a problem (contact groups will be considered as valid WAC groups), but maybe we should do something on the frontend to not show automatically-generated groups (there are many of them, possibly one for every AS collection).

Start by reading issue #1189 and locating the implementation of the custom `/_groups` endpoint; the payload does not name specific files or tests. Trace how WAC groups are currently created and stored, then determine what must change for ordinary named-graph resources under `/vcard/group`. Done means the custom path is no longer required and frontend handling of automatically generated groups is addressed.

Written by the indexing model from the issue text.