improve flexibility of can-connect behavior ordering

[nlundquist]

We've had several ideas on how to improve can-connect behavior ordering:

• algorithmically order behaviors based on their requirements
• create a connection "pipeline" of "stages" that behaviors define themselves as part of
• expose the canonical ordering of behaviors and allow user modification of it

The goal of any of these improvements would be to allow behaviors:

• to be attached to a connection in any order and still end up with a working connection (this currently works only for behaviors in the canonical ordering)
• to attach any required behaviors that are missing from a connection
• to be documented as part of a hierarchy easing understanding of the purpose of a behavior

[nlundquist]

To assist in this work I created a graph attempting to order the behaviors into stages and show what methods behaviors override of the connection. The graph is ordered from top to bottom with the edge labels showing the methods overridden on the connection by the lower behaviour.

I've attached a .gif export of the graph and a zip of the original OmniGraffle document.

behaviors relayout.zip

[nlundquist]

Whatever solution we implement should allow modification of existing connection types like #291 describes. This will allow "higher order" behaviors.