SemanticClassificationType should not be internal

[forki]

This is needed downstream for ionide and FSAC.
Already merged to fsharp/FSharp.Compiler.Service (see fsharp/fsharp-compiler-docs#696)

[dsyme]

@forki At the moment all these types are internal (or should be) in FSharp.LanguageService.Compiler (the name given to the internal Microsoft compilation of the compiler service component in the Visual F# Tools distribution of F#). FSC is not an official API in the Microsoft shipped DLLs, and it's Microsoft policy to make everything internal that's not part of an official API. The internal attributes are one of the remaining sources of divergence between FCS and this repo

There should actually be tests that check that all types are internal this so I don't know why those wren't failing. Maybe they have been disabled somewhere along the way.

It is possible that we will decide to break Microsoft policy and allow public types in these APIs. Ot maybe we should use a whole swag of #if in order to dual-compile, which would probably allow us to bring the last remaining diffs across from FCS - @brettfo @KevinRansom @cartermp @Pilchie may have opinions which way we should go.

Basically the tension is between two states of existence:

1. FCS as it is today: a fast-and-loose no-guarantees community API/nuget package, with frequent major version revisions and no real binary-compat story.
2. FCS as a Microsoft component, possibly with a binary compat story.

cheers
don

[smoothdeveloper]

@dsyme regarding the policy, can this be bypassed by simply stating that FSharp.LanguageService.Compiler assembly as a whole is not by any mean a public / supported API? This can also be stated in the assembly description.

Having the code totally align on this with FCS one will for sure make things easier in the frequent merges you have to do.

Currently, it is difficult to contribute code which:

• can be built as part of VisualStudio.sln (depends on FSharp.LanguageService.Compiler)
• doesn't depend on VisualStudio assemblies (not put in current FSharp.Editor project)
• depends on FCS when built for other tooling

Such code would make a spot for all F# tools to leverage, we still don't have that and the community is copy/pasting features among the various tools.

I see opportunity in having assembly which can be compiled with either FSharp.LanguageService.Compiler or FCS and believe such assembly should be maintained in this repository (so the features can be integrated to VS).