Refactoring: Editor Hover

Refactoring: Editor Hover

This item is about refactoring the editor hover code. It is here to serve as a reminder of work to do:

• The editor hover status bar should be created inside of its corresponding class, not outside. It can be accessed from outside then through a getter.
• Rewrite https://github.com/microsoft/vscode/blob/d38b24bf7ab6318bf69a5898857013f4c277a998/src/vs/editor/contrib/colorPicker/browser/standaloneColorPickerWidget.ts#L231 so that we do not register disposables within the rendering function. Registration should happen ideally a limited number of times, not on every rendering.
• Rewrite https://github.com/microsoft/vscode/blob/d38b24bf7ab6318bf69a5898857013f4c277a998/src/vs/editor/contrib/hover/browser/contentHoverRendered.ts#L25, to merge RenderedContentHoverParts and RenderedContentHover. Place the fields into an object (for example called 'source' or 'metadata') that will contain the additional data. Do not use a wrapper.
• Do not keep two objects in hover controller and markdown hover participant that represent essentially the same thing. Have only one object representing the hover state and call the methods directly on them. Consider changing the IHoverPart so that it contains the field isExpandable, the corresponding accessibleContent and a method which allows one to update the hover part and the editor content hover. This way we can get place all of the recent work concerning the verbosity of the hover into the MarkdownHover type directly instead of keeping it inside of the participant directly
• Draw a UML diagram of the whole feature area and understand the interplay of the classes and the data flow, in order to understand how to optimally refactor the code.
• The _currentResult is essentially defined more or less at the same time as the _renderedContentHover field. Can these be refactored to make this clear?