Allow to load CountPerOp info from mupen64plus.ini

The CountPerOp settings has to be adjusted for each ROM. It is easier for the
enduser when the default value is not hardcoded in mupen64plus and instead
this dynamic information is retreived from the mupen64plus.ini.
Add CountPerOp info to mupen64plus.ini

The CountPerOp settings has to be adjusted for each ROM. It is easier for the
enduser when the default value is not hardcoded in mupen64plus and instead
this dynamic information is retreived from the mupen64plus.ini.
Avoid level restart through lianes swinging in Donkey Kong 64 (U/J)
Fix self-references in mupen64plus.ini.
Fix incorrect md5 references in mupen64plus.ini.
Remove unused SDL2 surface in compat code

mupen64plus doesn't support 2D video output because it forces OPENGL mode.
Unfortunately, the rest of the compat code still assumes that surfaces for 2D
data are used and overwrites the data when the window is changed.

The surface code can be removed to avoid these problems.
Close SDL2 window when quitting Video subsystem

SDL2 doesn't close windows anymore when the video subsystem is closed.
Therefore, the window created by the SDL2 compat layer has to be closed
manually to avoid orphan windows in frontends like m64py in non-VidExt mode.
Zuzma says that Hydro Thunder plays without freezing if the CountPerOp is set to 1
Avoid SDL_GetWindowSurface to fix crashes on wayland

Instead of trying to access the wayland window through SDL_GetWindowSurface,
it seems to be easier to just use a pseudo surface which is not really used by
anyone (except the size information).
Save link information in *AL(L) instructions unconditionally

All "Jump and link" and "Branch and link" like instructions save the PC in the
target register unconditionally and not only when the branch/jump is taken.
The specification is not clear whether the store is actually made before or
after the delay slot and therefore the behavior of the dynarecs ("link" before
delay slot) is used.

Reported-by: Nebuleon <nebuleon.fumika@gmail.com>
Allow multiple preconditions per cheat

Each cheat code can have multiple preconditions which all have to be fulfilled
before it can be executed. The default implementation in mupen64plus could not
handle these extra test codes because a failed test only caused a jump over the
next cheatcode (ignoring whether is also a test or a non-test cheatcode).

Therefore, all (negative) results before a non-test cheat code have to be
aggregated. The first non-test cheatcode evaluates the result of the
preconditions and only executes the non-test cheatcode when no precondition
test failed. The earlier results are always dropped after a non-test cheatcode
to allow a fresh start.
Use same precondition for all parts of the Mario64 Leviate cheat

The cheat code consists of three pairs of precondition and actual write. The
original code used two different preconditions (one for the first write and two
for the second/third write). This caused problems like the inability to finish
a level. Using the same precondition everywhere seems to fix this problem.
add option to build for hard floating point arm environments
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."