Region Adjacency Graph

## Example Images
![figure_1](https://cloud.githubusercontent.com/assets/3823490/3291718/5ce9b952-f587-11e3-8c29-e2aace6d7794.png)
![figure_2](https://cloud.githubusercontent.com/assets/3823490/3291723/7074b134-f587-11e3-8c73-d28222891a21.png)


@vighneshbirodkar Under either min or max, a hierarchical merging of the edges up to some threshold is equivalent to simple thresholding. I'm not clear right now on which is which but you should be able to figure it out. That would be a good choice for default behaviour, and you could justify it in this way.

Regarding my point 5, the key is that, given the current control flow, there is *no* `weight_update_function` that the user could pass that would allow him to update this kind of edge. (Unless you mean overload `merge_nodes`, which I think is not a good idea.) I think that the right functional form can certainly be found that would allow arbitrary update rules.

Here's my current thinking:

1. rename `i`, `j`, and `k`/`x` to `src`, `dst`, and `neighbor`. This will make things much more readable long-term.
2. give the function the signature `weight_update_function(g, src, dst, neighbor, *extra_args, **extra_kwargs) -> float`.
3. the function then knows that we are merging node `src` into `dst` and considering what will be the weight of the edge `(dst, neighbor)`. It can access all the other relevant weights, edge data, node data, etc., as required.

What do you think? @ahojnnes @vighneshbirodkar @stefanv?