reimplement: SHC_3BB0A8C1_0x00479C80 optimization issues

[TheRedDaemon]

This one might need AI work. I was unable to produce the 100% match due to the way the second loop variable is computed:

0x479cb9 : jne -0x14
0x479cbb : -lea eax, [esi + 1]
           : +mov eax, 1        (findSamplePlaceForSoundUnk.cpp:27)
0x479cbe : pop esi
0x479cbf : -nop
0x479cc0 : cmp dword ptr [edx], 0       (findSamplePlaceForSoundUnk.cpp:28)

Common sense tells me both loops need to be forward. Apparently, the original did not allow the compiler to "know" the start value of the second loop and made it dependend on the internal run value of the first, or the compiler decided here to use lea instead of mov, while having to pad with a nop then.

The rest seems to fit. I created a temporary global in the cpp file to simulate the struct variable access. It uses one of these direct "add" that do not work for the resolver.

So, current state:

• Issue with loop run values (maybe).
• Struct Resolver shortcoming, therefore currently temporary for tests.

Would be cool if you could try this one also with the AI method, under the assumption it is not too confused by the resolver issue.