Make the Rust API more lazy

[hhirtz]

Right now algorithms are run eagerly:

coupe::Rcb { iter_count: 2, ..Default::default() }
    .partition(ids, (points, weights))
    .unwrap();
coupe::KMeans::default()
    .partition(ids, (points, weights))
    .unwrap();
coupe::FiducciaMattheyses { max_imbalance: Some(0.05), ..Default::default() }
    .partition(ids, (adjacency, weights))
    .unwrap();

Could coupe make do with less computations? It would mean we'd need to have a global view of the algorithm chain, something used like iterators?

trait IntoPartitioner {
    fn into_partitioner(&mut self) -> Partitioner<'_>;
}

ids
    .partition()
    .with_vertex_coords(points)
    .with_vertex_weights(weights)
    .with_adjacency(adjacency)
    .rcb(coupe::Rcb { iter_count: 2, ..Default::default() })
    .k_means(Default::default())
    .fidducia_mattheyses(coupe::FiducciaMattheyses {
        max_imbalance: Some(0.05),
        ..Default::default()
    })
    .collect() // ?
    .unwrap()?;

[hhirtz]

The partition type also needs to be reworked.

Since even before the trait rewrite in #9, the way to store a partition is a Vec<PartId>, which has the advantage of being easy to use and pass around, but also poses a number of problems:

• The number of parts can only be guessed (is wrong when a part is empty) and is O(n) to compute. This leads to weird APIs like coupe::imbalance::compute_part_loads and part-info's -n option,
• Metrics like the imbalance and the edge cut have to be stored separately (or, in current master, recomputed every time an algorithm needs it).

As a middle point between the two suggestions above, we could have a smart Partition type (name TBD) that keeps track of relevant metrics and is updated by algorithms.

[hhirtz]

Some difficulties I'm encountering with coupe's current API with the [num-part port]:

• it's difficult to access a specific metadata from an algorithm run when you accept any algorithm. For example the number of iterations,
• algorithms can't run in parallel because the Partition trait requires &mut self because some algorithms like Random have internal state that is updated during a run. Although this ended up not really needed since spawning the rayon threadpool on all threads ends up really time consuming compared to the algorithm iterations, so I set RAYON_NUM_THREADS=1 instead.