Set up CI with Azure Pipelines yml

[azure-pipelines]

No description provided.

[enricosada]

some random notes:

• rename the target build as Pack, because inside there you do dotnet pack
• DefaultTargets="Test;Build seems strange, these two target are not dependent on each other, so do not trust the order. so in the build script, run the dotnet msbuild /t:Build and a dotnet msbuild /t:Test separately
• refactoring the name property $(Name) ihmo is annoying, make things harder to read. i understand copy past, but really every repo is different anyway

[bartelink]

• agree with renaming to Pack, but was assume callers were going to do dotnet build etc. One thing this does not cover is if a repo has stuff to Test, Build and Pack - I was using this Build doing the pack, and msbuild doing Test+Build hack as a way to make the yaml copy-pasteable/diffable.
• was not 'trusting' the order, but per msbuild it does define the order, so a dotnet msbuild tuns tests first this way, which is what you want
• I'm kinda fond of the $(Name) (it was not my invention), but agree it should go

I won't fix these in this PR; feel free to if you happen to have time and inclination (I'll do this to CallPolly and Jet.JsonNet.Converters as a batch)

[enricosada]

Making things explicit help, more so with things not so commonly used (less magic).

• dotnet msbuild build.proj ppl need to know about DefaultTargets.
• dotnet msbuild /t:Pack build.proj is explicit.

And the yaml can just dotnet msbuild /t:Pack build.proj, or dotnet pack build.proj
and after that, dotnet msbuild /t:Test
and adding a <Target Build just to dotnet build is small too

Ihmo The yaml file is not a part who should be copy pasted as is, it's a part of this repo, and can and will be different on other repos (everyone is a bit differnt anyway). we can share and minimize diff, without creating hidden conventions.

[bartelink]

I agree with all your points; thanks for laying them out so clearly. I'll apply that philosophy in each of the repos at a later point ;)