Fixes #885

This is designed to fix both reading and writing of edge spells (and deprecated edge slices) on `.gexf` format graphs.  

The existing `add_spells` and `add_slices` methods are sufficiently generic in implementation to support serialization/deserialization of spells/slices for both nodes and edges and as such remain _functionally_ unchanged.  Parameter names for the `add_spells` and `add_slices` methods have been changed in several instances though, to reflect the handling of either nodes _or_ edges.  For example, ` def add_spells(self,node_element,node_data):` becomes  `def add_spells(self,node_or_edge_element,node_or_edge_data):`.

Calls to the relevant `add_spells`/`add_slices` methods have been added during both deserialization of a `.gexf` graph file's edges to networkx format (read) and during serialization of a networkx graph's edges to a `.gexf` file format (write).

Below is an example Gephi `.gexf` file __some_file.gexf__.  I illustrate the difference in output between the current networkx implementation and the implementation with this fix applied, assuming that __some_file.gexf__ is read in with networkx and written straight out again:

__some_file.gexf__:
```
<?xml version="1.0" encoding="UTF-8"?>
<gexf xmlns="http://www.gexf.net/1.2draft" version="1.2">
    <graph mode="dynamic" timeformat="date">
        <nodes>
            <node id="0">
                <spells>
                    <spell start="2009-01-01" end="2009-01-15" />
                    <spell start="2009-01-30" end="2009-02-01" />
                </spells>
            </node>
            <node id="1">
            </node>
        </nodes>
        <edges>
            <edge id="0" source="0" target="1">
                <spells>
                    <spell start="2009-01-01" end="2009-01-15" />
                    <spell start="2009-01-30" end="2009-02-01" />
                </spells>
            </edge>
        </edges>
    </graph>
</gexf>
```

Reading `some_file.gexf` and immediately writing back out to some other file with _existing_ networkx implementation (missing edge spells):
```
?xml version="1.0" encoding="utf-8"?><gexf version="1.1" xmlns="http://www.gexf.net/1.1draft" xmlns:viz="http://www.gexf.net/1.1draft/viz" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema-instance">
  <graph defaultedgetype="undirected" mode="static">
    <nodes>
      <node id="1" label="None" />
      <node id="0" label="None">
        <spells>
          <spell end="2009-01-15" start="2009-01-01" />
          <spell end="2009-02-01" start="2009-01-30" />
        </spells>
      </node>
    </nodes>
    <edges>
      <edge id="0" source="1" target="0" />
    </edges>
  </graph>
</gexf>
```

Reading `some_file.gexf` and immediately writing back out to some other file with _fixed_ networkx implementation (edge spells appear):
```
<?xml version="1.0" encoding="utf-8"?><gexf version="1.1" xmlns="http://www.gexf.net/1.1draft" xmlns:viz="http://www.gexf.net/1.1draft/viz" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema-instance">
  <graph defaultedgetype="undirected" mode="static">
    <nodes>
      <node id="1" label="None" />
      <node id="0" label="None">
        <spells>
          <spell end="2009-01-15" start="2009-01-01" />
          <spell end="2009-02-01" start="2009-01-30" />
        </spells>
      </node>
    </nodes>
    <edges>
      <edge id="0" source="1" target="0">
        <spells>
          <spell end="2009-01-15" start="2009-01-01" />
          <spell end="2009-02-01" start="2009-01-30" />
        </spells>
      </edge>
    </edges>
  </graph>
</gexf>
```

Finally as a side note, there are some bugs with other aspects of `.gexf` serialization/deserialization.  For example, the serialized output graph `mode` attribute is `static`.  i.e. it is not honouring the `dynamic` graph mode specified in the input file.  This, and a few other issues are orthogonal to the fix under consideration though and I will create separate issues for them.