Feature request: Support structured hoverKind

[DylanGuedes]

Hello,
gopls has a new hoverKind named structured, which may enhance how editors show hover documentation. Since it looks kinda enriching, I would like to suggest vscode-go to add support for this hoverKind and to maybe enhance the syntax highlight in that case.

An example of what gopls returns when hoverKind=Structured:

{"signature":"func (*ReceiptPriceFiller).FillReceiptPrice(receipt *models.Receipt, cache dataLayer.CacheDAL, isDirty bool) (fallbackFlow bool, cacheErr *redis.Error)","singleLine":"func (*ReceiptPriceFiller).FillReceiptPrice(receipt *models.Receipt, cache dataLayer.CacheDAL, isDirty bool) (fallbackFlow bool, cacheErr *redis.Error)","synopsis":"FillReceiptPrice fills the given receipt price based on the set of rules of this filler and returns if the fallback flow was activated and if some Redis error happened.","fullDocumentation":"FillReceiptPrice fills the given receipt price based on the set of rules of\nthis filler and returns if the fallback flow was activated and if some Redis\nerror

[hyangah]

@DylanGuedes Interesting. Do you have any specific idea and example on how to utilize the structured hover data?
It looks like VSCode+gopls FullDocumentation already offer some syntax highlighting (if not perfect).

[DylanGuedes]

Actually, I found this because I was trying to understand why VSCode wasn't highlighting anything in the documentation. One idea would be to just apply Markdown highlighting to the fullDocumentation attribute because that would split lists into different lines in expected scenarios. For instance, right now, if I have this doc (source):

// deletePod deletes the pod from the internal state of the kubelet by:
// 1.  stopping the associated pod worker asynchronously
// 2.  signaling to kill the pod by sending on the podKillingCh channel
//
// deletePod returns an error if not all sources are ready or the pod is not
// found in the runtime cache.

VSCode pops this:

If it used Markdown to parse this, that could be:

 `deletePod` deletes the pod from the internal state of the `kubelet` by:
 1.  stopping the associated pod worker asynchronously
 2.  signaling to kill the pod by sending on the podKillingCh channel

 `deletePod` returns an error if not all sources are ready or the pod is not
 found in the runtime cache.