Flaw with the way API set resolution is handled

The current implementation for resolving API sets (used when rebuilding the IAT) will fail if an API set is present in the import directory and uses a patch number not included in the map. Whilst not extremely common, this happens from time to time and will likely result in a mapping failure.

If you look at the way the Windows loader does API set resolution, a binary search is used with the `API_SET_HASH_ENTRY` structures. The important thing here is the fact that the `Hash` field of this structure excludes the patch number, meaning all comparisons done during resolution are independent of the patch number.

Following this logic, `api-ms-win-core-processthreads-l1-1-0.dll` and `api-ms-win-core-processthreads-l1-1-3.dll` will map to the same DLL. In fact, any API set like `api-ms-win-core-processthreads-l1-1-X.dll`, will map to the same DLL.

Using the current implementation, a fix is simple enough. Instead of doing an exact match via a key lookup, do a comparison up until the patch number.

As a reference, my library uses a stripped-down [version](https://github.com/Dewera/Lunar/blob/8f8c7d9365ca250f4252c406d1bcaddb73f8b3a5/Lunar/RemoteProcess/PebAccessor.cs#L131) of the same resolution algorithm that the Windows loader uses, which illustrates how the patch number is excluded from lookups during resolution.