Improve WARP merge conflict handling

[fuzyll]

Version and Platform (required):

• Binary Ninja Version: 5.3.9216-dev, 5.3.9218-dev
• Edition: Ultimate
• OS: macOS
• OS Version: 26.3.1
• CPU Architecture: aarch64

Bug Description:
Under circumstances I am not entirely sure about, merge conflicts on WARP function GUIDs can occur in Enterprise between two users. When they do, it's entirely unclear to the user what they should do to resolve things properly:

Steps To Reproduce:
Not quite sure right now, happened during a RE//verse demo.

Expected Behavior:
I actually think these probably shouldn't be merge conflicts at all and should be resolved automatically? But, I am not entirely sure of how this works under the hood.

Additional Information:
I have both .bndb files, message me.

[emesare]

Ideally what would happen is the GUID would be thrown away and a flag set on the function to have the guid regenerate, since the guid is derived off the shape of the function, it necessarily is tied to whatever other changes were made between DB versions (e.g. sections, segments, base address, no returns, jump table resolution) so it does not make sense to show it at all to the user.

As for how to actually resolve it automatically, WARP is a plugin not integrated into the core, utilizing the function metadata to persist the guid, im not sure how to programmatically involve myself in the conflict handler to remove the guid, perhaps we add a "on conflict" field to metadata objects, i think it would be like "on_conflict": "drop" or something.

[CouleeApps]

Fixing this actually needs a core change, namely that when function metadata was added, the relevant merge code was not updated to account for it. I'm adding the ability to merge function metadata keys and hopefully can add code to WARP to handle its values specifically

[CouleeApps]

To handle merge conflicts from the WARP plugin, we first need to implement the ConflictSplitter class in the rust API. Due to how close this is to the code freeze, I'm planning to do the following:

1. Add a special case for WARP in the core for the release
2. Implement a rust API for custom ConflictSplitter subclasses on a PR, for merge after the release
3. Have the WARP plugin use the newly added rust API on a PR, also for merge after the release

[CouleeApps]

Fix was implemented as described in the comment above. Leaving this open and pushing back to the next release, tracking merging the API-based solution after the stable.