Improved nice print to give literal values

[En3Tho]

This change enables pretty printing Const values. Need some help with deciding printing manner (currently I'm using parentheses to show literal value). Also, I'm not sure I used WordL api right but I hope I did.
Screenshots are from JetBrains Rider.
Seems like mapping from NumbericLiteral could be fixed in Rider as it reports wrong color for mkNumericLiteral, but okay with mkStringLiteral:

[auduchinok]

Seems like mapping from NumbericLiteral could be fixed in Rider as it reports wrong color for mkNumericLiteral

Good timing, it has been fixed yesterday. 🙂

[En3Tho]

Yep, all good now! Thanks @auduchinok

[saul]

The bracket syntax is a bit strange IMO. Would it be better for the tooltip to be:

val SomeFloat : float32 = 15.23f

[En3Tho]

@auduchinok pointed out that val name could be reported as literal and highlighted accordingly. I can try address that in another PR.

Also, there are lots of static values like WordL.equals, WordL.colon, but they are not used in NicePrint.layoutNonMemberVal function. Instead they are being created anew every time. Should I try to find such places and replace keywords and language elements with statics? In another PR.

All that if this gets merged of course :0
What about tests on this thing? Do I need to add something?

[En3Tho]

@saul

The bracket syntax is a bit strange IMO. Would it be better for the tooltip to be:

Already fixed :)

[cartermp]

val name could be reported as literal and highlighted accordingly

Yeah, this is where things get weird. Is it more correct to show it as a normal val in tooltips, since it's a value? Or go much further on differentiating it as a literal? I would personally prefer the latter but I know that it's quite intentional that there's much less distinction between things in the F# design, and @dsyme has expressed as much in other PRs about tooltips like this one: #9563

[auduchinok]

We could probably classify it properly at the FCS level so it would be up to the tooling if the additional info should be used. VS integration could then ignore the additional colors and fallback to the current ones where needed.

[cartermp]

Oh, I would personally color it differently in VS. That was the crux of my argument in favor of differentiating more, that editors have more options available to them.

[cartermp]

What about tests on this thing? Do I need to add something?

Testing is definitely lacking on this front. I suppose we'd be happy to have the start of a test suite here, but I don't think that's a prerequisite to get this merged.

[En3Tho]

@cartermp Hey Phillip! Can you merge this please or there are some more things I need to do before that?