Integrate merge log to repair mesh topology with breaks

[fcollman]

Is your feature request related to a problem? Please describe.
I want to run mesh analytics in blender on neuron segmentations from CAVE that have sometimes gaps in the segmentation. The most reliable source of where those breaks are and how they should be crossed is in the PCG merge log. I would like to have my blender mesh also have the extra edges that are defined by that merge log included in the mesh so that shortest path calculations run smoothly across these gaps.

Describe the solution you'd like
MeshParty has a module in it that is dedicated to the steps that are required here. https://github.com/CAVEconnectome/MeshParty/blob/master/meshparty/trimesh_repair.py
I'd love to figure out how to integrate this functionality into Navis, and ultimately into the blender integration, but it perhaps could be useful to some of the skeletonization methods you have as well. I think there are many ways of going about this so i thought i'd get your thoughts. Generally the trimesh native object can't support this because it doesn't have any sense of edges outside the edges defined by the faces. Blender's meshes do have just edges that are not faces. MeshParty stored this around as a separate set of "link_edges" [Nx2] index array into vertices that could be used by various mesh methods to give a reasonable graph. I don't know what you think the best way to accomplish these goals are in a way that lets you utilize this information. I can also imagine different ways of dividing the responsibility here.

In general the caveclient doesn't really know anything about meshes right now. CloudVolume does, so we could try to push it there, but again cloud-volume meshes don't have a sense of these kind of extra edges either right now.

[schlegelp]

This probably needs just a few surgical changes in navis, some of which you already identified in your PR. I like the idea of link_edges or extra_edges.

Where it gets tricky are parts where navis (or skeletor for that matter) use the trimesh representation. Perhaps we can subclass trimesh.Trimesh and add the concept of non-face edges where we need it.

I'll try to identify the various bits where we'd need to rejig things slightly today.