Separate out Model class into cython _GraphManager and python Model

[wbernoudy]

Move almost all functionality of the previously cython Model class into a new cython _GraphManager base class that has only private methods. The new python Model class chooses which of these methods to expose publicly. This will aid in adding the new Expression class which will expose a different set of the methods on _GraphManager (see #166).

Still TODO if we go with this approach:

• Rewrite the docstrings on the now private _GraphManager methods
• Clarify what should happen with States, Symbol, ArraySymbol etc that have now been moved to dwave.optimization.graph_manager

[arcondello]

So if I am understanding correctly, the idea (once we add Expression) is

• _GraphManager manages ownership of a C++ Graph and the States
• _Model is the Cython parts of Model
• _Expression would be the Cython parts of Expression

right?

[wbernoudy]

So if I am understanding correctly, the idea (once we add Expression) is

* `_GraphManager` manages ownership of a C++ `Graph` and the `States`

* `_Model` is the Cython parts of `Model`

* `_Expression` would be the Cython parts of `Expression`

right?

That's the idea. Though currently, I still have methods on _GraphManager that are common to both Expression and Model which we may also want to move into another Python class (e.g. to_networkx()).

[arcondello]

IMO it might make sense to go from 5 to 3 by skipping _Model and _Expression. You've already made all of the methods private on _Model so I think it's OK if Expression has a _binary() method, but not a binary() method.

That way _GraphManager's scope becomes quite clear - to wrap the C++ methods in Python ones. And then the subclasses are simply choosing which to expose.