SymbolStartAnalysisContext: Add support for VB

[martin-strecker-sonarsource]

#8799 introduced the SymbolStartContextWrapper and also added a dependency to Microsoft.CodeAnalysis.VisualBasic.Workspaces to the CFG project. Subsequently issues like #9022 appeared on Peach and for customers. As a quick fix, we removed the dependency to Microsoft.CodeAnalysis.VisualBasic.Workspaces in #9027 effectively dropping VB support in RegisterCodeBlockStartAction and RegisterSyntaxNodeAction.
We should re-enable support for VB for both methods.

#9028 is a stub-implementation on how such support can be implemented without relying on Microsoft.CodeAnalysis.VisualBasic.Workspaces. Another approach would be to cache <string, Delegate> instances of dynamically typed lambdas which can be Delegate.DynamicInvoke. This would also involve MethodInfo.MakeGenericMethod and returning a compiled Delegate (because it would be open generic) instead of Action<...> from the Linq.Expression.

[pavel-mikula-sonarsource]

Could this be solved by code duplication? To create the necessary class in VB analyzer and let the magic that requires VB reference happen only in that class?

[martin-strecker-sonarsource]

That would break the API I'm afraid. The api is RegisterSyntaxKind<TLanguageKindEnum> where TLanguageKindEnum is either VB.SyntaxKind or CS.SyntaxKind. If we move the implementation, the whole wrapper gets split and the idea to be able to move to a new Rsolyn version, remove the wrapper and all work as before would be broken.
#9028 is much better approach and #9077 mentions other options as well. In the worst case, we just go dynamic which should also work.