Recursive patch merging

[taorepoara]

When using the << operator between two patches, it merges them together.

For now if both patches have the same field defined, we use the right end value.
It would be better IMO to merge both values if they are patches.

This lead to a problem: Option.

Merging Option patches is not implemented by default and can't be implemented.

I see 2 solutions to fix that:

1. Change the implementation of Patch<Option<P>> for Option<T> where T: Patch<P> to use a custom struct: OptionPatch. The best choice IMO since we can implement easily other traits on this new struct.
2. Adapt the derive to always implement Shl<Option<$patch>> for Option<$patch> which could lead to many unuseful implementations

@yanganto What do you think ?

[yanganto]

#43 modify the option example with <<, and everything looks good.

Can you please modify the example for me?
Such that it will see a use case we can not fulfill.

The example is also the spec when we need to implement something, the way is like TDD, we can make sure what we will do always fits the user's need. The example is not in vain.

[yanganto]

Thanks for the clear example about the bug. ❤️

I have another solution for this.

3. just remove shl for patch, so the user can not patch on a patch.

What do you think about it?

[yanganto]

If you want to solve this, we can keep it. The implementation is up to you. For me, 3 is good. 😄

[yanganto]

fixed by #45