Rationalize OmniSharp versions

[DustinCampbell]

Today, the only notion of version in OmniSharp are the releases and tags on GitHub. However, that isn't reflected in the assembly versions. It would be ideal if assemblies were properly stamped with a version and the version was displayed on OmniSharp launch.

[filipw]

+1000

Also, branch dev should go in favor of just master.
And the versions we release from GH should just be regular semantic versions - i.e. 2.0.0, 2.1.0, and so on.

[DustinCampbell]

Yeah, I think the only thing holding us up is that we're all a little confused as to what constitutes 2.0.0. Where should we call it ready? For example, should we wait until we're off project.json? Should we wait until we drop .NET Core standalone releases? Should we wait until we drop the http infrastructure and make it a plugin?

[filipw]

Right, then let's call it 1.10.0, 1.11.0 and so on - until there is an clear view of what constitutes OmniSharp 2.

[david-driscoll]

I've had good success with GitVersion in other projects, atleast that helps with stamping versions.

[DustinCampbell]

Right, then let's call it 1.10.0, 1.11.0 and so on - until there is an clear view of what constitutes OmniSharp 2.

Makes sense to me.

[david-driscoll]

the new csproj makes this even easier now, as there is a new task that generates all the assembly attributes for you..

[DustinCampbell]

Cool. That gives me incentive to get back to making the macOS/Linux builds work on .csproj.

[DustinCampbell]

Now that the dev branch is gone, I think we only need to get version stamping going to address this issue.