This makes the popup disappear if you keep typing or enter inser mode or
move the cursor etc.

I found it jarring that previously it would just move the cursor behind
the popup and such until you hit escape. Makes the popup more "modal"
but without actually stopping you from continueing.

Also:

- Use simliar up/down keys as the symbol finder (c-p, c-k, c-n, c-j
  etc.)
- SetupFoo -> SetUpFoo because the verb is "To set up" (rather than the
  noun "a setup".
- purge barbaric 80+ character lines

We try to be a bit consistent with the finder poppup, but
implementation-wise this is simpler. The idea is that there are 3
columns, each having 1/3 of the popup width. We fix the width of the
popup (like we do for the finder) and set the tabstop to 1/3 of the
internal width (core_width).

Then when displaying text, we truncate "columnns" according to that
tabstop (to avoid mess). To do this, we pass structured data from the
python layer to vimscript and construct the line text there. This will
also help later when we add in the syntax highlight (text properties)
like we have for the finder popup.

This basically involves moving the properties mapping to its own place,
and creating text properties to overlap the various parts of the popup
columns. Style matches, and feels correct.

Fiddly part is that we have to (for some reason) set cursorline every
time we move the cursor, but ain't nobody gonna be able to explain why,
and why that only necessary after launching the finder popup window
once. Some wierd vim bug is my guess.

This makes the columns seem less broken, particularly for leading
whitespace. This is particularly problematic due to our use of tabstop:
if the leading whitespace was a tab, it would go nuts.

It would still go nuts for any other literal tab in the description.
Perhaps we should fix that too.

…resizing

Previously, when changing direction of hierarchy and re-rooting the
hierarchy tree, we would retain the old node as the new root.
That works most of the time, but fails in the face of multiple
inheritance and switching to supertypes. In that, problematic, case, the
resulting hierarchy will be missing some supertypes.
Worse, if a call hierarchy contains a node with multiple locations,
re-rooting to that node behaved in a way that defies explanation.

The solution is to throw away everything and start a new hierarchy
completely every time a user requests re-rooting.

This trades some performance for correctness, but this is not at all
performance sensitive.

In order to send a ycmd request for an unloaded buffer one must first...
load the buffer.
That is the only way to reliably determine the buffer's filetype.
However, we do not want to switch to the buffer, so everything needs to
be done "in the background".

`:badd` adds a buffer as unloaded, if it were not present before.
`bufload()` loads a buffer that has previously not been loaded.

Previously all new nodes were counted as 1.
With call hierarchies, there may be more locations/lines per hierarchy
node. In that case, the cursorline would be set to the wrong line.

Instead, we need to add up the lengths of all the item locations.

Changelog:

1. Upgrade all subservers
2. Hierarchy support

Previously the tests were using async result checking, but this is
intended for insert mode only. In fact we were running off the end of
the test and then the check callbacks were firing.

Simplified by just making it the same but sequential, and replacding
FeedAndCheck* with direct calls to feedkeys(..., 'xt').

indexof was added so recently that even vim-helptag-versions website
doesn't have it. Replace with a loop.

There were some unnecessary `WaitForAssert()` calls and unnecessary
`silent` commands.

- `badd` is unnecessary since we have `GetBufferNumberForFilename()`
- Instead of passing `location`, we can pass `file`, `line` and `column`
  separately.