Support icon resource fetch on LSP protocol, multiple content types.

[sdedic]

Originally, the TreeView in (vscode) LSP client fetched node information and it got icon resource bits encoded in data: URI. To make the payload smaller, both the LSP client and server implemented a cache: server sent only the entire icon data only the 1st time with an unique id, and sent only that id afterwards.

This PR only sends image URI, and lets the client to ask, if necessary, for the resource bits. The client may substitute the images from its local resources and never ask the server.

Icons that provide their resource URLs are served by reading that URL's contents and base64 encoding to the LSP protocol response. Icons without their own URL (typically from L&Fs) are still painted on a virtual surface, converted to PNG. To avoid situation where the client receives an URI, then the LSP server restarts (crashes), and then the client asks again the PNG bits are stored in the var/cache folder using name hashed from the contents. So even if the server never generated the icon, it can serve the bits from that cache after restart.

The image content type is taken from URL connection - works OK for gif, png, svg (image/svg+xml MIME type). Works OK in vscode client (URIs like data:image/svg+xml;base64,.....). Possibly rebranded images are supported - even a case when a SVG rebrands an original GIF seems to work OK.

There's an additional fix in the vscode client: if a Node disappears after the client receives children response with that node's ID and before it asks for node's info, the client receives an "invalid node" data (id: -1). This PR prevents the node from entering the child list - and if an already existing tree item is updated, this 'invalid' response results in parent's refresh request.