SymbolDB: Multiple symbols detection allowed

[sepalani]

This PR allows multiple functions with the same stripped name to be patched.

NB: This PR doesn't fix the misused array, check this PR instead.

---

This change is

[BhaaLseN]

If you change that line anyways, why not stick to this one instead? Or rather, fix it anyways since its bound to cause a conflict either way.
And, this isn't really visible from the diff, but is the singular version still being used somewhere?

[sepalani]

I decided to separate both PR because one of them is unrelated to this change (git is pretty convenient concerning conflict resolution so it's no big deal). Then I know that the other one shouldn't impact anything else.

I found one place where the singular version is used, but I'm not sure that the only one and if it matters. It's in the Debugger_SymbolMap.cpp file in the function AddAutoBreakpoints enclosed by preprocessor directive. The code seems just to automatically add a breakpoint where PPCHalt is located and I've never found this function more than once. Plus, its signature is present in the totaldb.dsy, so unless someone adds it manually to a map file it shouldn't appear more than once.

However, if you want me to get rid of the singular version I can replace it, anyway.

[sepalani]

I figured out that games can have multiple times the same function, so I did the same for the GetSymbolsFromHash method. Should I get rid of the singular version ones?

[sepalani]

I used a std::set in order to map a hash to multiple address/symbol. Now, multiple symbols are detected properly, but... As expected, some of them are just false-positive. Furthermore, the checksum system is pretty inefficient right now. Functions with different codes are detected as the same symbol, not really accurate indeed (i.e. lhz r0, 0x5000(r3) equals lhz r0, 0x5004(r3) according to the checksum system).

However, most "system" functions are detected accurately. And by the way, due to these recent changes in the OSReport/Logs system, a lot more debug messages are printed.

In sum, if you don't care about this function detection inaccuracy, this PR is ready to be reviewed & merged. Otherwise I'll close this one and make another WIP PR where the goal would be to rewrite those in order to be the more accurate possible.