API changes after removing stored Graph from Hilbert

Created by: gcarleo

Since we are still in beta, I believe it is a good time to discuss some possible changes to the APIs.

Here is one issue that has emerged discussing with @PhilipVinc : for future developments it would be important to have more flexible Hilbert objects, that are not necessarily bound to a Graph. These objects would naturally allow for example to define heterogeneous hilbert spaces (say an ensemble of spins and bosons, of spins and fermions etc), and also perform product of two or more Hilbert spaces automatically.

For example one could do

n_spins=10
n_bosons=10
n_sites_bosons=12

hi = nk.hilbert.Spin(s=0.5,n_spins)*nk.hilbert.Boson(n_sites_bosons,n_bosons) 

or just double the hilbert space, when considering density matrices

n_spins=10

# doubled hilbert space for density matrices 
hi = nk.hilbert.Spin(s=0.5,n_spins)*nk.hilbert.Spin(s=0.5,n_spins)

In general it is cumbersome to carry along the Graph object inside Hilbert, since strictly speaking the only thing Hilbert needs to know is the number of sites and the local quantum numbers, not the structure of the edges etc.

In practice this means that the Graph object now stored in Hilbert should be removed. As a consequence, a few classes now deducing Graph from Hilbert should accept Graph in the constructor. For example

# Ising spin hamiltonian 
ha = nk.operator.Ising(h=3.0, hilbert=hi)

would become

ha = nk.operator.Ising(h=3.0, hilbert=hi,graph=g)

and similarly for RbmSpinSymm.

For Hamiltonians-like objects, it might make sense also to just do

ha = nk.operator.Ising(h=3.0, graph=g)

and then ask ha to compute/return the Hilbert space when needed (since Ising in this case also defines the local hilbert space, so strictly speaking we don't need to pass it in the constructor).

I believe that these interface changes are not a huge problem, but I wanted to have some comments before doing these breaking changes.