Only resolve using complete rom database entries

The old rom database algorithm tried to resolve (refMD5) entries immediately in
romdatabase_open without checking the referenced entry. This algorithm caused
entries to be used when they are still have uninitialized fields because the
referenced entry still has some other entries which it referenced.

Using only complete (resolved) entries also allows to detect loops
(unresolvable references) as seen before
304bf8c4de6824ed09b71622a23662f9111a660b ("Fix self-references in
mupen64plus.ini")
Don't overwrite rom specific settings during resolve phase

The behavior of the romdatabase_resolve was to overwrite any setting when the
referenced rom had non-default settings. This made it impossible to use
references when the referenced rom has different settings than the rom who
references it.
Use normal cheat engine to run workaround cheats

Instead of hardcoding special commands in cheat_apply_cheats, it is easier to
just use add the codes to the active cheats list when the the rom is started.
This avoids having more string compares and similar things in this regularly
called routine when more workaround cheats are added.

This is especially helpful against the slowdowns in the Zelda debug roms caused
by the "Warning: Ocarina of Time version could not be determined.  No fixes
applied." spam on the console.
Add Zelda OoT cheats to mupen64plus.ini

It is a lot easier to add the workaround cheats to the mupen64plus.ini instead
of having them hardcoded in the cheat engine. The data is currently not used
because it still has to be parsed by the romdatabase before these general
workaround cheats are supported.
Parse cheats from from mupen64plus.ini

The workaround cheats are easier to manage over the mupen64plus.ini instead of
hardcoding them inside the mupen64plus-core source code.
Add note about (broken) Pilotwing64 shadow fix

This fix is used in PJ64 to avoid the big landing shadow block. But it can
cause hangs when the user presses Quit (can be reproduced in PJ64+m64p when
using the rocket in 3FCD4969F9A080BD2BCB913EC5D7A3BD).
Add workaround to make Pokemon Snap controls working and images selectable

The controller problem seems to be related to the graphics plugin. A quote from
darkmaster14

"I believe the Pokemon Snap input issue is closely related to the missing red
 dot issue. If you recall, in the original hardware, when you first arrive on
 the beach, there's a small tutorial where you can't move the cursor until you
 take a picture of the first few Pokemon that show up. Once you finish the mini
 tutorial, you can move the cursor around as you please. Well, the red dot
 doesn't work on most plugins, so the game doesn't detect the cursor locking
 onto the first few Pokemon, so the tutorial doesn't work, and thus the input
 never gets unlocked.

 Well, I got a hold of a very buggy port of FatCat's software renderer plugin
 for Mupen64Plus, and the red dot works on that, which lets you do the tutorial,
 and thus the cursor movement is unlocked and you can play the game as normal.
 So really, the problem most likely lies in the video plugins rather than the
 emulation core. I'm guessing on Project64, however, they added a hack to force
 the cursor to move around despite the red dot not working, which is why it
 works on that emulator."
Add missing read mode check in flashram_command -> execute
Merge pull request #12 from ecsv/ini_cheats

Move workaround cheats from cheat to PJ64-like ini settings