Implement differing byte search

[agarmash]

This PR implements a neat little feature I missed - the ability to jump to the next/previous differing byte, skipping the chunk of repeating bytes. Very useful when you analyze a raw flash dump and want to skip the large sections of 0x00s/0xFFs.

Some implementation details worth validating:

• I wasn't sure what is the correct place to put the new menu entries into. The possible candidates were File -> Go to address... and Edit -> Follow selection. I chose the former, although the latter may be a better fit since it already states that the action is related to the selection. Overall, it may be a good moment to refine these menu entries in general.
• I didn't add any tests since I'm not sure what is the project's policy for those. Please let me know if I need to add some!
• I added the machine-generated translations for the new menu entries which may be considered a questionable thing. Please let me know if you're unhappy with those, I'll drop the commit.

Also, thanks for such a nice tool, I use it a lot and was glad to build a new feature for it!

[paxcut]

This PR implements a neat little feature I missed - the ability to jump to the next/previous differing byte, skipping the chunk of repeating bytes. Very useful when you analyze a raw flash dump and want to skip the large sections of 0x00s/0xFFs.

Is this feature implemented in some hex editor you used before? I couldn't find anything like that to compare against. Your implementation seems like it only skips repeating bytes but a more general approach would skip words, double words, etc so if say the repeating pattern was 0xAABB you could also skip until the next different word,

I wasn't sure what is the correct place to put the new menu entries into. The possible candidates were File -> Go to address... and Edit -> Follow selection. I chose the former, although the latter may be a better fit since it already states that the action is related to the selection. Overall, it may be a good moment to refine these menu entries in general.

Neither one of those seems like they apply. While it is true that the cursor position is being changed, there are lots of ways to move the cursor that don't necessarily belong in one of those two. What is important is the way in which the cursor is moved. In this case it is by searching, so the feature should be in the File>find menu as a separate tab of the existing hex and ascii options. The code should also be using the existing search code for the hex editor. This has the additional benefits of not having to create new menu entries and also the need to duplicate all the code that deals with providers or searching.

I didn't add any tests since I'm not sure what is the project's policy for those. Please let me know if I need to add some!
I added the machine-generated translations for the new menu entries which may be considered a questionable thing. Please let me know if you're unhappy with those, I'll drop the commit.

If there are tests for the search feature in the hex editor thats where additional tests for the first difference should be. If there aren't then don't worry about adding one. I sorry but for translations we require that native speakers translate all the text shown in ImHex and we don't allow AI translations of any kind.