Leaking DLL handles

[Y-Less]

There's no cleanup in SharpVk.Interop.NativeLibrary. A standard setup will call SharpVk.Instance.EnumerateExtensionProperties, SharpVk.Instance.EnumerateVersion, SharpVk.Instance.Create and probably more. All of these create new instances of NativeLibrary, all getting a handle to vulkan-1.dll, but none of them cleaning it up again.

[FacticiusVir]

NativeLibrary was always a bit of a hack to handle the different DLL names on different OSes; the helper methods on Instance that create it were written on the assumption you'd only call them a small number of times when the app starts. There are overloads that accept a CommandCache instance (which wraps NativeLibrary), so you can create it once and re-use it; but now that .NET Core 3 has improved DLL mapping I need to revisit how that whole section works.