Refactor add_constraints complex loop conditional

This refactoring breaks the conditional inside the loop in `add_constraints` into two separate methods to better see their purpose. Eventually @tenderlove and I intend to remove the need for these separated methods altogether.

The changes allowed us to move the `last_chain_scope` method call outside the loop. `get_bind_values` must match this section of `add_constraints` because of how the bind value caching works. Then the code was refactored to use `each_cons` instead of `chain[i + 1]` in `get_bind_values`. The use of `each_cons` makes it clear we need to get the `next_reflection`.

There is more work that needs to be done before `chain[i + 1]` can be removed from `next_chain_scope/add_constraints`. 

I'm open to be names for `last_chain_scope` and `next_chain_scope` if anyone has better ideas :smile_cat: 

As mentioned in previous PR's this is part of a larger refactoring to make `add_constraints` a clearer, DRYer method.
Given that `add_constraints` and `get_bind_values` have to be kept in agreement about the order, I think I'd slightly prefer for this to live at the end instead of the beginning... assuming that doesn't otherwise uglify matters.