Visualize extra GFA / LastGraph attributes

[fedarko]

All of these are "extra" features that aren't needed for an initial release, but could be nice to have.

The GFA attributes should be prioritized, I think (since more assemblers output GFA than LastGraph, as far as I am aware). For consistency's sake, we should try to handle these data somewhat analogously to how GfaViz handles them.

GFA 1 attributes

• Include containment lines as edges (??? maybe, not sure if this is a good idea; would need to be clear about this, and probably ideal to have a CLI option that toggles this behavior). Alternatively, work this in with Visualize overlap attributes of edges (resolve ambiguities in GFA/LastGraph files) #47?
• Include jump lines as edges (also a maybe, but more reasonable)
• Store paths as "pre-defined" paths (aka "scaffolds," but we should really rename that UI section to just say "paths") in the visualization that the user can toggle through
• Store walks as "pre-defined" paths similarly (I guess, but parsing these seems kind of complex; is this worth it?)

GFA 2 attributes

• Include gaps as edges (maybe)
• Use unordered groups as patterns (maybe; we can probably be strict and say that the nodes in these groups have to be connected to each other, i.e. the induced subgraph must comprise a single weakly connected component)
• Store ordered groups as "pre-defined" paths

LastGraph attributes

• Store SEQ blocks as "pre-defined" paths
• Store NR information (reads contained within nodes)? I don't remember seeing any Velvet graphs that include this info; it may be sufficient to just record the number of reads contained within each node.

[fedarko]

Groups (U or O lines) should be simple to include—U lines (subgraphs) can be encoded as Misc. Patterns in the graph, and O lines (paths) can just be represented as scaffolds I guess (but as mentioned above baking scaffolds into the graph representation will take some work).

SEQ blocks in LastGraph files can just be encoded as scaffolds, similarly to O lines. Easy solution = writing a script to just convert these into AGP files the user can upload into the viewer interface; hard solution = modifying the .db to include these sortsa paths.

[fedarko]

Yeah, this would be a useful feature to support. A potential idea for the future is modifying MetaCarvel to output oriented.gml as a GFA file, with scaffolds encoded as O lines.