Add a .NET 7.0 target and a DllImportResolver

[0xC0000054]

Related to #10

This is required for the library to support the Apple mobile/embedded platforms that use AOT (IOS, TvOS, WatchOS).
These platforms have libheif built as a static library and merged into the AOT compiled application.

The DllImportResolver would redirect requests for libheif to the main binary, similar to the following:

if (libName == "libheif")
{
  if (OperatingSystem.IsIOS() || OperatingSystem.IsTvOS() || OperatingSystem.IsWatchOS())
  {
    return NativeLibrary.GetMainProgramHandle();
  }
}

The DllImportResolver may also be helpful on Windows, where the build system usually defaults to naming the library heif.dll.
If a user forgets to rename heif.dll to libheif.dll, the existing code will throw a DllNotFoundException.
This may not be as critical because the LibHeifSharp readme notes that the native library must be named libheif.

Because the DllImportResolver may be called multiple times for the same native library, the native library handle should be loaded once and cached for future requests.

The DllImportResolver will be registered using a Module Initializer to ensure it is configured before any P/Invokes are called.
It turns out that module initializers are not supported for class libraries. Use a static constructor on the LibHeifNative class?

[0xC0000054]

I have decided that the DllImport resolver should be handled by the client code, it is too big a maintenance burden for the core library.

Adding additional target framework(s) would require updates to be released when a runtime goes out of support.
I also have no way to test if a non-Windows DllImport resolver actually works.

Instead, I will be adding code to the libheif-sharp-samples repository and page to the project wiki that demonstrates how to register a DllImport resolver for LibHeifSharp.
This also has the advantage that it works with any version of LibHeifSharp and consumers can customize it for their specific needs.