Adding support for using WinSQLite3.dll from WinRT.

[ali-hk]

Adding support for using WinSQLite3.dll from WinRT, which is built into Windows 10.10586.0 and above.

This has a few benefits:
-Apps don't need to include sqlite3.dll in their packages if they use WinSQLite3.dll
-WinSQLite3.dll may already be loaded into memory since some OS components use it, reducing load time.

For more information, see: https://msdn.microsoft.com/en-us/windows/uwp/data-access/sqlite-databases#using-the-sdk-sqlite

[StefanFabian]

This would be a nice change.
However I think it would be better to create an abstraction for each rather than using a bool to switch between them.

[ali-hk]

@StefanFabian I initially wrote it that way as a separate class library but decided against it for these reasons:

• Most of the code in the .WinRT project would be duplicated.
• Because of the way the platform binaries are packaged and included in projects based on NuGet's concept of platforms (TxMs), the separate abstraction (call it .WinSQLite) would either:
  1. need to specify uap as its TxM. This isn't a good option, as UWP apps would be forced to use the .WinSQLite abstraction. This is undesirable because some may want to use a custom or existing sqlite3.dll that's in their package, or may need to support Windows 10.0.10240.0 which doesn't have winsqlite3.dll
  2. need to specify portable-win81+wpa81 as its TxM. This also isn't a good option as it would mean both the .WinRT and .WinSQLite platform abstraction binaries would be included in all Windows 8 and 10 apps, unnecessarily increasing their package sizes when they're only ever going to use one or the other.

Alternatives are:

• Add the WinSQLite platform abstraction to the .WinRT project, allowing reuse of the mostly shared code. This is ok, but there wasn't a precedent for that in this codebase so I didn't do that. If that's ok with @oysteinkrog then I'm willing to make the change. Here's what this would look like: ali-hk/SQLite.Net-PCL@1097536d88be05d0a4c82ac68a3fff412180af16
• Package the .WinSQLite abstraction as a separate NuGet package. This is also an ok option, but you'd have to know to look for it when adding the packages to a project. Here's what this would look like: ali-hk/SQLite.Net-PCL@c953de965f46a685c7c78840d3a5d9fbc40c7846

[oysteinkrog]

I think I would prefer having it as a separate platform abstraction, but I think it would be best to keep it in the same project/nuget to avoid complicating things.
I'm merging this now though, we can always change it later, and if anyone wants to send a PR to do so feel free :)

Thanks for your work :)