Introduce so called expandable groups:
* reference in them are displayed inline.
* in the filter component they are prefixed with a text separator
indicating the group.
* on branches panel they are expanded and displayed as separate refs.
GitRefManager:
* group local branches into expanded group;
* group tracked remote branches into expanded group;
* group other remote branches into separate groups by the name of
remote.
BranchesPanel:
* draw expanded groups inline.
* for true-groups draw the name of the group as if it is a reference.
* clicking on the group shows a popup with the list of references.
* clicking on the reference navigates to the commit, in the same way
as it is done for single-references.
Existing problem: multiple-root branches with same names (both on the
panel and in the filter).
Count each task for loading more details sequentially, when creating it.
If then we get a LoadingDetails object from the cache,
which is very old, it means that its task was skipped
because of our limitation to avoid execution of all loading tasks (the
limitation is valid, because we don't want to have hundreds of tasks
for commits which user just scrolled through).
In that case remove the fake LoadingDetails object from the cache,
and let a new task to be submitted.
DetailsPanel, Actions:
Don't ask the Graph about nodes or details of the selected rows,
because in the case of non-graph filter the result will be incorrect.
Instead take the value from the table model.
Let the CommitCell hold the Hash value. In some cases it might be
null (for example, when there are "empty" lines in the table
containing only graph fragments).
Let DataGetter return value for the hash, not only for the node.
This can be slow potentially, will be optimized or moved to the
background later.
Let Copy Hash action operate on Hash instead of VcsFullCommitDetails.
Make Cherry-Pick and Open on GitHub be unavailable if details of the
selected hashes were not loaded yet.
Seems to be too aggressive right now, and better solution was not
found yet.
Making nodes & edges thicker is kept, so current branch is indicated
anyway.
* It looks like Git is able to filter faster on its own,
than return us details.
* It is one step less, therefore if there are not many details,
user will wait less time.
* It consumes less memory, since we don't expand the cache by extra n
commits.
The code which handles "load more" is kept in the VcsLogDataHolder by
now: maybe this decision will be changed or somehow modified.