Fix unsafe integer usage by using string keys instead

[daniel-wer]

In skeleton.js a recursive cantor pairing was used to combine three integers into a unique single integer which is used as a Map key. However, these numbers quickly become very large, exceeding javascript's Number.MAX_SAFE_INTEGER. In that case, the Map access to delete edges will fail sometimes resulting in wrongly colored or left over edges.
I switched to a simple string concatenation approach to create the unique keys. According to a quick search this shouldn't be much slower and I didn't notice any slow-downs.

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• Open an empty tracing and drag-and-drop this NML into it
  orphan-nodes.zip
  • Make sure the tracing is empty so that the IDs are not relabeled!
• Jump to position 198722, 346458, 5801 and reload the page to fix an issue with the 3D view if annotations are far outside of the dataset
• Remove the node there, then delete the smaller of the two agglomerates that were created by the split
  • On master you'll see some left over edges without nodes and warnings in the console ([Skeleton] Unable to find buffer position for id 78519564543334160, ...)
  • On this branch the agglomerate should be correctly deleted without any left over edges

Issues:

• fixes 3D viewport shows orphan nodes and edges after splitting tree and deleting one component  #5158

---

• Updated (unreleased) changelog
• Updated (unreleased) migration guide if applicable
• Updated documentation if applicable
• Adapted wk-connect if datastore API changes
• Needs datastore update after deployment
• Ready for review

[philippotto]

Awesome fix! Great testing steps, too 👍 Worked perfectly.

and reload the page to fix an issue with the 3D view if annotations are far outside of the dataset

I did not see this for master nor for this branch. Is this something we should take care of?

[daniel-wer]

I did not see this for master nor for this branch. Is this something we should take care of?

No, I don't think so. I have only ever encountered this during development where I sometimes use NMLs from much larger datasets. This is not a real-world use case, I would say.