Since it can technically merge any hash with objects that respond to `==`

Passing a parent_id will limit ancestors upto the specified parent if
it is found.

Using `ancestors` and `descendants` the `base` relation will not be included

So only methods that are used elsewhere are public.

When projects were listed after groups, the projects that would also
have been listed on the last page containing groups would be repeated.

When filtering we want all to preload all the ancestors upto the specified
parent group.

- root
  - subgroup
    - nested-group
      - project

So when searching 'project', on the 'subgroup' page we want to preload
'nested-group' but not 'subgroup' or 'root'

And fix some pagination bugs

By preloading the count of members, projects and subgroups of a group,
we don't need to query them later.

We also preload the entire hierarchy for a search result and include
the counts so we don't need to query for them again

We do the wrapping in an array in represent_hierarchy for children.

When finding children for a group

And document what extra queries are still being performed.

The children are lazy-loaded when expanding

The possible cases are:
 - [Array, Array]
 - [Array, Hash]
 - [Array, GroupHierarchy]
 - [Hash,Hash]
 - [Hash, GroupHierarchy]
 - [GroupHierarchy, GroupHierarchy]