Dataset cleanup - Store API for graph method


Cleaning up Dataset class, adding graph tracking to store API, as
discussed in #307

Summary of changes: 

 * added methods ```add_graph``` and ```remove_graph``` to the Store
   API, implemented these for Sleepycat and IOMemory. A flag,
   ```graph_awareness``` is set on the store if they methods are
   supported, default implementations will raise an exception.

 * made the dataset require a store with the ```graph_awareness```
   flag set.

 * removed the graph-state kept in the ```Dataset``` class directly.

 * removed ```dataset.add_quads```, ```remove_quads``` methods. The
   ```add/remove``` methods of ```ConjunctiveGraph``` are smart enough
   to work with triples or quads.

 * removed the ```dataset.graphs``` method - it now does exactly the
   same as ```contexts```

 * added a ```default_union``` flag to Graphs, ```ConjunctiveGraph``` has this set to True, and ```Dataset``` to False

 * cleaned up a bit more confusion of whether Graph instance or the
   Graph identifiers are passed to store methods. (#225)

Comments: 

 * The use-case where a Dataset exposes only some of the graphs that
   exist in the store is not supported.

 * I have not thought about transactions, and how creating or removing
   a graph fit into a transaction. It is sort irrelevant, as we do not
   have any transaction-aware stores.


Questions:

 * Should dataset.context return the default graph?
   ```dataset.quads``` return ```None``` as context for the triples in
   the default graph, this would suggest "no". (currently it does)

 * Do we really need dataset.graph AND dataset.get_context?
   ```get_context``` return a Graph, but does not create it.
   ```graph``` creates the graphs AND will also make a new graph
   identified by a skolemized bnode if called without arguments.

 * Should it be possible to disable ```graph_awareness``` for a Store?
   The only change would be whether a graph is removed once it is
   empty. I guess noone relies on this, as it is not implemented
   correctly in ```IOMemory``` or ```Sleepycat``` at the moment :)