Semantic snippets don't fallback to VS options properly

[DoctorKrolic]

Version Used:
Latest main

Description:
Since semantic snippets are controlled by roslyn completion providers, they are not only suggested only in valid contexts, but can also use other APIs to benifit their users. One of such features is respecting user's code style options. For instance, for and forr snippets try to respect preference for using var vs int in loop header. We can easily test this by adding an .editorconfig document with the desired options to the test workspace and verify our results. And we have such tests in place. However, .editorconfig is not the only way to control code style settings. When it is not present, snippets should correctly fallback to VS options and respect them instead. Unfortunatelly, currently this is not the case.

Steps to Reproduce:

1. In you VS options set code style option 'var' preference/For built-in types to Prefer 'var':
   
2. Make sure you don't have an .editorconfig file in your solution, so it cannot override VS options
3. Execute for snippet where it is allowed

Expected Behavior:

for (var i = 0; i < length; i++)
{
    $$
}

Actual Behavior:

Additional info:
I've debugged this problem and the cause seems to be here:

roslyn/src/Features/Core/Portable/Snippets/SnippetProviders/AbstractSnippetProvider.cs

Lines 163 to 165 in bacd78c

	var addImportPlacementOptions = await document.GetAddImportPlacementOptionsAsync(fallbackOptions: null, cancellationToken).ConfigureAwait(false);
	var simplifierOptions = await document.GetSimplifierOptionsAsync(fallbackOptions: null, cancellationToken).ConfigureAwait(false);
	var syntaxFormattingOptions = await document.GetSyntaxFormattingOptionsAsync(fallbackOptions: null, cancellationToken).ConfigureAwait(false);

It seems like all options share the same pattern of how we are getting them. In our case the problem is in simplifier options, but I believe other options won't fallback to VS options as well. By looking at the definition of GetSimplifierOptionsAsync it doesn't seem like fallback to VS options is by design there. The method only checks for analyzer config documents (aka .editorconfigs). So as far as I can tell the fix here is to somehow get VS options and provide them as fallbackOptions instead of nulls. It would also be great if we can have an easy way of testing VS options with the same ease as we can test .editorconfig ones.

[jhinder]

See also #71542 and #70092.