Add deterministic ability ID generation to PermanentImpl.addAbility

[jimga150]

Fixes #11560
Does NOT fix #10372 - Most likely due to the Effect ID changing each call (CopyEffect.java:copyToPermanent)

Potentially an alternate solution to #10802

I'm open to suggestions about the methodology for generating the new UUID. I wanted to adhere to the following requirements:

• must be able to handle using a single seed ID (in case the ability ID and sourceId are null) and output a different UUID from the input in that case
• must not cycle in case of multiple chained addAbility calls (if you XOR UUIDs together, you'll wind up with A ^ B ^ A = B)
• must be deterministic

I considered using RandomUtil, but converting multiple UUIDs into a single long for setSeed would reduce the seed space by a big factor and increase the probability of UUID collisions. I don't know if that's significant or not, but i didn't want to chance it with this change that has such widespread implications for the engine.

[jimga150]

It's been a while since i've done a PR, but it looks like the failures in the build are just the oracle checks and rarity/ability hint verification, etc. Is there a true failure in the build? I thought the oracle checks were turned off for GitHub PRs?

[JayDi85]

Verify test failed. It’s not related to PR. Mtgjson got update with fixed rarity in one of the new cards, so master start to fail.