Move back the ContextQuery related extensions and corresponding SyntaxFact APIs up to the shared WorkspaceExtensions project

Split `ISyntaxKindsService` into two parts:

1. `ISyntaxKinds`: Pure data query interface, which already exists in CompilerExtensions shared project and can be used by analyzers.
2. `ISyntaxKindsService`: The `ILangaugeService` implementation of `ISyntaxKinds`

Above split ensures that we can move the `ISyntaxKindsService` language service implementation down to the WorkspaceExtensions project, which in turn ensures that `GetLanguageService<ISyntaxKindsService>` will always succeed in our entire code base. This is currently not true in CodeStyle fixes layer due to the fact that the language service implementation is defined in Workspaces.csproj

Split ISyntaxFactsService into two parts:

1. `ISyntaxFacts`: Pure data interface to query about syntactic facts. This is moved to CompilerExtensions shared project and can be used by analyzers.

2. `ISyntaxFactsService`: Derives from ISyntaxFacts and ILanguageService and is present in the WorkspaceExtensions shared project. This enables Code fixes and Workspaces layer to access the same functionality via a language service, i.e. `GetLanguageService<ISyntaxFactsService>`.

Note that we cannot use a partial declaration for `ISyntaxFactsService` instead of `ISyntaxFacts`. This causes `ISyntaxFacts` to be defined in both the CodeStyle analyzer and CodeStyle fixer assembly (former imports CompilerExtensions and latter imports WorkspaceExtensions), which leads to type conflicts. We also cannot follow the approach taken for `ISyntaxKindsSevice` as it defines the second partial declaration `ISyntaxKindsSevice` which sub-types `ILanguageService` in Workspaces project, leading to the language service not being defined in CodeStyle fixer assembly, which will cause any code fix requesting `GetLanguageService<ISyntaxKindsService>` to fail. The only feasible approach for us to have the functionality available in shared analyzer layer is to split out the pure data query part of the service to a separate type, as done in this PR. I will send a follow-up PR to also split `ISyntaxKindsService` similarly. Hoepfully, these two are the only language services that are commonly used by our analyzers, and we will not require any more such splits.

Extracts out the changes to core Workspace changes from https://github.com/dotnet/roslyn/pull/41363.