Refactoring hydrator

@davidwindell, @ocramius

This is the beginning of the refactoring of the hydrator, using the byref/byval logic.

Basically, we get rid of the ClassMethods hydrator, people will have to follow some conventions on the naming.

The extracting phase is done (I hope) correctly for both byref/byval.

I still want ocramius to explain exactly why a user would need byref or byval (I mean, I know what by value and by reference means) but WHY it would chooose one over another).

For the hydrating phase, and to answer to davidwindell answer, I think that the cleanest way is to introduce strategy that are called when hydrating collections.

For instance, the intersectionUnion would become a "AllowRemove" strategy, so that if elements are not present in the posted collections, the strategy allow to remove them from the original collection, or a DisallowRemove that would do what david wanted (does not remove elements from original collection even if they are not posted).

The AllowRemove would need the user to define a removeSomethings, as well as a addSomethings that will be used to insert new elements.

What we need : 

* List all the strategies we want by default
* What we need to take care for the byref thing in hydrating (especially about the inverse side).