made venus span mapper to deal with typescript better

Add EditorConfig settings for source formatting

Allow extension methods on tuple receivers when underlying conversions are "upcasts"

Fixes #16517 

Merge dev15-rc3 into master

Extensions methods declared on bases and implemented interfaces are allowed to be applied to receivers that of derived or implementing type.

This change extends this rule to tuple receivers as long as the rule holds for individual elements, recursively.

I.E. valid "this" conversions are:
- identity conversion
- implicit reference conversion
- boxing conversion
- (new)  implicit tuple[literal] conversions as long as all underlying conversions are valid "this" conversions.

Move Roslyn dependencies from VSSetup to VSSetup.Dependencies

Allow CausalityBreakpoint in FunctionResolver.ShouldHandleRequest

Allow the C# compiler to run on Mono again

Use global options in SupportsFormattingOnTypedCharacter

Don't crash perf.runner if a test crashes

Temporarily marks data flow analysis over a region which contains local
functions as "failed." The current implementation is incorrect, so data
flow analysis should mark the result as bad rather than knowingly give
an incorrect result.

This change also causes extract method to emit a warning when extracting
over a region which involves local functions.

Fixes #15532, #16116, #8719, #8718, #8717

* Add regression test for #16399

Closes #16399

Upgrade Linux use of portable targets

Emit forwarded types in a deterministic order

MSBuild team fixed the issue we were seeing in the portable targets and
now we can remove the work around we added for it.

https://github.com/Microsoft/msbuild/issues/1533

adding comment following PR feedback.

Revert "Vsix cleanup"

Bind operator statements when requesting optional parameter values

**Customer Scenario**: Referencing the latest Microsoft.Net.Compilers package and try to run csc.exe on Mono fails. (This was
found building the xplat branch of MSBuild.)

**Summary of Change**: Don't use System.Runtime.InteropServices.RuntimeInformation in Compiler, Workspace or Features layers

**Details**: Recently, we took a change to use `System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(...)` to detect the
current platform. The API is designed such that different implementations are delivered via NuGet depending on the TFM. For .NET
Core, this works great. When restoring an app using Microsoft.CodeAnalysis on Windows, a Windows implementation is delivered. And,
when restoring the same app targeting macOS/Linux, a Unix-specific implementation is delivered. However, for apps targeting
.NET Framework (such as the desktop compiler), this design presents a serious problem. Essentially, the Windows implementation
is always picked for .NET Framework apps (such as net451, net46, etc.). So, if that app is then run on macOS or Linux on Mono,
Microsoft.CodeAnalysis will *think* it's running on Windows and start reporting errors because path separators are pointing the
wrong direction.

OOM for file mappings

Fixes #16167

Vsix cleanup

Move our references over to Dev15

Have Narrator announce that an Inline Rename session has started

Do not run Naming Styles on overrides, etc.

fixed multiple issues that caused checksum mismatch

Merge dev15-rc3 into master

make sure all IDE analyzers implement IBuildInAnalyzer

Improve method type argument inference around nullable tuples.