API Ordinals differ in each Windows version; retdec decompiler may assign wrong function names

There are reverse conversion tables (import ordinal -> import name) in files like `support\ordinals\x86\kernel32.ord`. During decompilation, they convert functions imported by ordinal into a human-readable API name. Some of them probably come from 16-bit Windows (`support\ordinals\x86\kernel.ord`). At that time, import by ordinal was Microsoft-recommended way to import APIs.

Since introduction of 32-bit Windows, import by ordinal is no longer recommended. In fact, ordinal numbers are not guaranteed to be constant across Windows versions. An example is [this regression test](https://github.com/avast/retdec-regression-tests/blob/master/features/exotic-pe/imports_tinyW7.ex), which originates from [Corkami's](https://github.com/corkami/pocs/blob/master/PE/imports_tinyW7.asm) collection. The author meant to call `msvcrt!printf`, followed by `kernel32!ExitProcess`. Both these APIs are imported by ordinal.

As the ordinal numbers shifted over time, the sample now calls `msvcrt!iswspace` a `KERNELBASE!AfpAdminDisconnect` (Windows 10 build 19041).

If you ask the "Why no one noticed this earlier" question, this is because normally, in 32/64-bit Windows, API names are almost never imported by ordinal, except for `WS2_32.dll`, `OLE32.dll`, few from `COMCTL32.dll` and possibly some others. The above mentioned sample is artificially created in a way that linkers would never do.

TLDR: Majority of the `ordinal->name` tables are worthless; moreover they may create misleading information by assigning wrong API names.

Start with the reverse-conversion tables under support\ordinals\x86\, especially kernel32.ord and kernel.ord, and reproduce the behavior with the imports_tinyW7.ex regression test. Compare the ordinal mappings with the Windows-version behavior described in the issue; done should mean the sample's ordinal imports are not assigned misleading API names.

Written by the indexing model from the issue text.