[WIP] Resolve native library location from runtimes folder

[bording]

This is the LibGit2Sharp side of the changes that libgit2/libgit2sharp.nativebinaries#68 enables, which means it won't build until an update package is available.

This builds on top of the changes introduced in #1563, allowing the default native library path to be resolved from the runtimes folder, for all target frameworks (including mono).

I've embedded the runtime.json information from https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json, and added the Microsoft.DotNet.PlatformAbstractions package to be able to get the runtime identifier.

This lets the correct native library to be chosen based on the runtime identifier, which maps back to the OS that the code is being run on.

One immediate benefit from this change is that when using LibGit2Sharp on .NET Core inside an MSBuild task, the correct native library should be chose automatically.

@tmat @AArnott I think this should really simplify the MSBuild task scenario while we're waiting for MSBuild to support this directly!

[bording]

I know that there are some tests that will fail because of these new changes, so I'll be sure to fix those up once we get a new native binaries package on nuget.org.

[ethomson]

Sorry, looks like my long delay allowed some conflicts to creep in. :( Happy to merge this if you wouldn't mind fixing them up.

[bording]

Turns out this is a dead end. The work was done on a faulty premise.

The manual native library loading applying to the DlllImport attributes is a trick that only works on Windows, so while this approach looked promising in how it simplifies/aligns things, it doesn't actually work.

😢

The good news is that if we get the proposed changes in place to remove the need for the other native dependencies from our libgit2 build, then we don't really need to worry about this for the most part anyway.

Once we get that in place, we need to revisit all of the library loading code anyway, and I suspect we might end up removing the LoadLibrary \ dlopen extern calls altogether.