Explain the verifier's generated names (#if_condition, call results, …) on hover #195

Impact: the Found steps (and the Context tab) show values the verifier introduces, such as #if_condition, #switch_selector, #case_condition, #getUndoManager_result or extended#1. Users are not told what they stand for, so a step like ∀#if_condition #if_condition == (x > 0) does not make sense to them. #185 now shows every step the verifier sends (A1_56 has 19), so these names will be on screen more often.

Idea: hovering such a name explains it in plain words and points to the code, e.g.

• #if_condition → "the condition of the if at line 42" (click: go to line 42)
• #getUndoManager_result → "the value returned by getUndoManager() at line 17"
• #switch_selector / #case_condition → "the value switch checks at line 30" / "the case at line 31"
• #array_length, #try_branch, #catch_branch, #new_…, #operation_result, #expression_value likewise.

To find out:

• Whether the verifier already sends what is needed: the kind comes from the name (GeneratedNames in liquidjava: if_condition, loop_condition, ternary_condition, switch_selector, case_condition, try_branch, catch_branch, array_length, …_result, new_…), but the source line has to come from the translation table or a new field. Note the table is keyed by display name, so all #case_condition rows currently share one entry and would link to the same case.
• If not, what the verifier must add (likely a liquidjava issue/PR: a position per generated name).
• Where the hover lives: Found steps, Expected, the step diff and the Context tab.

Separate from #175 (line tags for instances of program variables, x@51), which covers names the user wrote; this issue covers the names the verifier makes up.