Add rr-debugger compatibility with POWER on Linux

rr-debugger (https://github.com/rr-debugger/rr) provides the ability to record a test case that fails, and conveniently navigate forwards and backwards using a gdb interface to examine the program at various program states.

This can be used to solve trivial faults (e.g. https://jira.mariadb.org/browse/MDEV-32439) without restarting a debugger/test case multiples times and each time stopping just a little bit easier to solve bugs hence being a time save.

Its big strength is solving multithreaded programs (e.g. MariaDB) where the problem exists however it only occasionally occurs. In this case a restart has more likelihood not the produce the problem so will waste a lot of time. On x86_64 bugs MariaDB has solved numerous bugs this way (https://jira.mariadb.org/issues/?jql=labels+%3D+rr-profile). With POWER's weaker memory model the missing of a memory barrier and multiple threads results in a much harder problem to solve. So having a rr supporting POWER would be idea. An example of this is https://jira.mariadb.org/browse/MDEV-30728. It was occasionally producible, always on ppc64le and nowhere else. A heroic effort by Timothy Pearson and Jens Axboe (https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/) eventually resolved it by trial and effort on the kernel side. With rr support on ppc64le identifying a crypto miscalculation after a context switch may have been able to more confidently define the problem to kernel developers and provide a narrower scope for resolution up to 6 months earlier. Without easy tools, the amount of time that can be spent on a single platform is limited.

rr support Intel, AMD and some Aarch64 processors because of the features offered in hardware.

What this requires is https://arxiv.org/pdf/1705.05937.pdf, explicitly the 5.1 hardware constraints.

The memory states can be tracked, and bpf filters are used for syscalls, however non-deterministically instructions, darn obviously, and larx/stcx can fail (e.g., due to a transient hardware condition or an OS/hypervisor interrupt). Without these conditions recorded the replay-ability may not be accurate. Even a partial solution before this hardware support is there might be worth while. Example aarch64 implementation with hardware - https://github.com/rr-debugger/rr/issues/1373#issuecomment-436270586.

The functionality implemented by this will be portable to the various supported languages by gdb (https://sourceware.org/gdb/) i.e. most compiled languages, and even scripting languages as a test case if causing a problem in the compiled language runtime.

The range of testimonials is impressive https://github.com/rr-debugger/rr/wiki/Testimonials.

Note a distro inclusion isn't a key requirement. Pulling down upstream source and compiling there is easy for all developers that would be the key userbase.