Migrate to SDK-based csproj files

[Thealexbarney]

This migrates all csproj files except ConcentusDemo to the newer csproj format.

• These projects can now be build with the cross-platform dotnet CLI.
• NuGet packages are automatically generated by the build system.
• There are now only two library projects: Concentus and Concentus.Unsafe. Both of these projects target multiple frameworks.
• I also fixed a few warnings, mostly related to XML documentation.

There are a couple things to look over. Let me know if I need to change any of these.

I saw your release notes about removing the net35 build from the latest NuGet package. I'm assuming that was because .NET Framework targets would choose the net35 build over the netstandard1.0 build. I added a net45 build so that wouldn't be an issue, and readded the net35 build.

I did my best to make sure all the build outputs were the same after the transition, but there's one difference with the .nuspec file. Csproj files don't have an option to set the summary in the nuspec file. (NuGet/Home#4587) I don't know if that's a problem or not.

I had to remove the PCL build. If the cross-platform MSBuild supports targeting PCLs, I'm not sure how to do it, and netstandard1.0 supports all the platforms that Profile259 does.

[Thealexbarney]

The PCL build has been readded, but it will only build from Visual Studio or full MSBuild.

[lostromb]

First off, thanks for the help. Sorry I haven't had much time to look at this in-depth yet but I did have one question to start with: do you have any suggestions for how to distribute the unsafe library? It seems on nuget I've seen 3 patterns:

1. Release as 2 separate packages in different flavors or with the unsafe version taking precedence over the safe one when it is imported
2. Release safe and unsafe versions of the same library in the same package (like SHA3 does) and allow consumer to reference one or the other
3. Release safe and unsafe mixed code which determines which version to use at runtime (like lz4net does)
   Thoughts / better ideas?

[lostromb]

Also to explain the PCL build: It's there because Windows / Windows Phone 8.1 projects seem to break in really strange ways when they try and import a NetStandard library using the older 2013/2015 toolchain. Like, compile would work fine, but then something with ARM IL code generation would break when you tried to deploy it to a device. It looks like you added back PCL support which is much appreciated.

[Thealexbarney]

No worries, I think we all know what it's like to be busy.

1. I think this is the cleanest option. There's no extra cost for consuming just the safe or unsafe version. And all it would take to switch from one to the other is adding or removing .unsafe in the project file.

2. Only downside to this one is that both dll versions are output at build/publish time by default. That'll cost either an extra 200 kb or the time to figure out how to make MSBuild not copy the version you don't need.

3. Would require reworking the library to choose between the two code paths at runtime. I don't know how much of a task that would be. You'd know better than I would. The built dll would be larger, depending on how much code the two versions share. I'm also not sure how platforms that require safe code would handle this one.

I was wondering about the need for the PCL build. I didn't know how to enable it at first, so I removed it until I figured out how to add the build. I saw that .NET Standard support was added to VS2013/2015, but didn't know if some tools still had issues with the .NET Standard assemblies.

[lostromb]

I'm guessing it's not possible to also maintain the old-format project files, perhaps as a separate solution? Almost all of my machines have VS2015 at the latest and I'm, uh, too lazy to upgrade all of them

[Thealexbarney]

It's definitely possible if you want to go that route. If there were two solutions, it would mainly be more work if you wanted to add a new project in the future or something.

[Thealexbarney]

Before I spend the time to create 2 separate solutions, is that something that would be acceptable?

[lostromb]

Sorry, I've kept you waiting long enough. I'm just going to merge this and then work out my own solution files later (or just migrate to vs2017 on my side I guess)