Re-architect formatting to prepare for cohosting (and for fun!)

[davidwengier]

I nerd sniped myself thinking about how to get formatting into cohosting, given the limitations Alex ran into doing the relayering for auto insert, and this is the result. I was going to go further and port the actual formatting endpoint to cohosting, but that would have ran into the same issue that Alex did with auto insert, so I figured I'd wait for that to merge, and put this up in the meantime.

This unblocks the formatting, code action and completion end points from being ported.
Part of #10743
Part of #9519

I strongly recommend reviewing commit-at-a-time, as I did this deliberately in an order, and in order to (hopefully) make reviewing easier. Though granted, there are a lot of commits.

[DustinCampbell]

Suggested change

	internal sealed record RazorFormattingOptions
	{
	public bool InsertSpaces { get; init; }
	public int TabSize { get; init; }
	public bool CodeBlockBraceOnNextLine { get; init; }
	internal sealed record RazorFormattingOptions(bool InsertSpaces, int TabSize, bool CodeBlockBraceOnNextLine)
	{

[davidwengier]

I kinda like not having to specify all options, but of course I realised that I stuffed up the default instance, so I've fixed that. I've copied the style from Roslyn (for example), except moved the static to the top since I'm not an animal. Let me know if you feel strongly about constructors vs initializers

[DustinCampbell]

At the very least, I would expect InsertSpaces and TabSize to be specified every time. If that's true, then maybe you could just add a default value to the CodeBlockBraceOnNextLine parameter.

All of that said, I'm definitely sympathetic to non-positional records. You lose deconstruction, but you also lose the friction of having to update constructors when you need to add more properties in the future. That's totally a judgement call and I'm happy either way!

[davidwengier]

That friction was my main motivation for this type existing in the first place. Plumbing through another flag on FormattingContext was what I started having to do, which led to the creation of this type. Also once Alex's PR is in, there is another flag to come here for FUSE. Though I will admit, having the last parameter be optional, and the new FUSE one, would probably be just as good, as they're only needed for full document formatting, so only one place would have to pay the price.

I'll think about it some more. Not merging this until Alex's PR is in anyway.

[DustinCampbell]

Looks great to me!

[ryzngard]