Can we add a RID for platforms that support WinRT native APIs?

Our scenario:

Our package:

Microsoft.Data.Sqlite
    runtimes/
        win7-(bitness)/
              native/
                   sqlite3.dll  <-- win32 version

For UWP apps, this causes problems (see aspnet/Microsoft.Data.Sqlite#245) because NuGet tries to add the win7 native asset (win32) and this does not pass the Windows App Cert Kit which does not allow calls to win32 APIs.

Our workaround:
We use an MSBuild script to replace the "wrong" sqlite3.dll (win32) with the right one, a version compiled for WinRT APIs instead.

 <Target Name="FixResolvedSqliteNuGetPackageAssets" AfterTargets="ResolveNuGetPackageAssets">
    <ItemGroup>
      <WrongSqliteNuGetPackageAssets Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-$(Platform)\native\*" />
      <ReferenceCopyLocalPaths Remove="%(WrongSqliteNuGetPackageAssets.FullPath)" />
      <ReferenceCopyLocalPaths Include="$(MSBuildThisFileDirectory)win10-$(Platform)\native\*" />
    </ItemGroup>
  </Target>

Where the workaround fails:
If Microsoft.Data.Sqlite is a transitive dependency, the MSBuild target does not run. We cannot fix the incorrect NuGet resolution.

A WinRT rid
Ideally, we'd like to drop the MSBuild hack altogether and have a package like this:

Microsoft.Data.Sqlite
    runtimes/
        win7-(bitness)/
              native/
                   sqlite3.dll  <-- win32 version
        winrt-(bitness)/
               native/
                   sqlite3.dll  <-- winRT version

UWP and other WinRT compatible platforms would get the WinRT native asset instead of the Win32 asset.

cc @ericstj @yishaigalatzer