Remove non-`gp_` and -`g6_` function wrapper methods from `Graph` and `G6(Read|Write)Iterator` Cython classes

[wbkboyer]

Background

During #38 , @john-boyer-phd brought up how there are some non-gp_ and -g6_ function wrapper methods associated with the Graph and G6(Read|Write)Iterator Cython classes that highlight a mismatch between how the EAPS planarityApp interacts with the graphLib vs. how the (currently private) edge-addition-planarity-suite-testing repository leverages the Cython wrapper.

Proposed solution

• Initialize the G6(Read|Write)Iterator with a Graph instance (i.e. __cinit__() would accept a Graph whose internal graphP would be passed as the second argument to cg6IterationDefs.g6_New(Read|Writ)er()))
• Remove:
  • Graph.get_wrapper_for_graphP() (since we should never have to get a new Graph wrapper for the graphP contained by the self)
  • G6ReadIterator.duplicate_currGraph() (since the owner of the G6ReadIterator should also own the Graph used to initialize the reader, they can directly call curr_graph.gp_DupGraph() to get a new Graph that wraps an independent graphP)
  • G6ReadIterator.get_currGraph() (since the owner of the G6ReadIterator should also own the Graph used to initialize the reader, there shouldn't be a need to get another wrapper of that same graphP)
  • G6WriteIterator.reinitialize_currGraph(), (since the owner of the G6WriteIterator will have access to the Graph, they should be able to directly run curr_graph.gp_ReinitializeGraph())
  • G6WriteIterator.update_graph_to_write() (since the owner of the G6WriteIterator will have access to the Graph, they should be able to directly run curr_graph.gp_CopyGraph(src_graph=next_graph))
• Update edge-addition-planarity-suite-testing workflows to more closely mirror planarityApp use of graphLib

Additional context

See this comment and this comment)