[zivshits]

Implements GUACAMOLE-181: granting access to every connection within a connection group currently requires checking each connection individually.

Following the approach described in GUACAMOLE-959, recursive granting is an explicit administrator action rather than a side effect of checking a group:

• Select All / Clear All in the header of the connection permission editor grant or revoke READ for every displayed connection, connection group, and sharing profile.
• All / None beside each organizational connection group grant or revoke READ for that group and everything within it.
• Checking a group's own checkbox is unchanged and still affects only that group.
• The contents of balancing groups are never affected, as those contents are not normally exposed to users having access to the balancing group. The balancing group itself is still granted/revoked, and balancing groups do not get their own All / None actions.
• While a filter is applied, only the matching items are affected, and the per-group actions are hidden (the hierarchy is flattened).

Changes go through the existing permissionsAdded / permissionsRemoved bookkeeping, so selecting and then clearing the same items results in no change on save. The editor is shared by the user and user group management screens, so both gain the actions.

Testing

Verified against the PostgreSQL extension with a tree containing nested organizational groups, a balancing group with a child connection, and a sharing profile, checking the saved permissions through the REST API after each save:

• All on a group: the group, its subgroups, their connections, and the sharing profile were granted; the balancing group was granted but its child connection was not.
• Clear All then Select All: everything revoked, then everything granted except the balancing group's child.
• Filter + Clear All: only the matching connections (and their sharing profiles) were revoked; groups and non-matching connections were untouched.
• Same behavior on the user group management screen.