Fix associations with a custom type for identifiers

I was running an experiment using a custom DBAL type, which converts a UUID string (in PHP) to 16 bytes binary string (in SQL) and vice versa, as identifier for a couple of entities. I noticed some associations weren't loaded correctly. This PR attempts to fix that issue.

I've included several tests:

- Loading a OneToOne association
- Loading a OneToOne association with composite identifier
- Loading a OneToOne association with composite identifier including a foreign one
- Loading a OneToMany association
- Loading a OneToMany association with composite identifier
- Loading a OneToMany association with composite identifier including a foreign one
- Loading a ManyToMany association
- Loading a ManyToMany association with composite identifier
- Loading a ManyToMany association with composite identifier including a foreign one

During the "_ManyToMany association ..._" tests I discovered the join-table wasn't populated properly. The columns were filled with the UUID string (in stead of the 16 bytes binary string). This has been addressed as well.

I've included these tests to verify that:

- Removing entities from a ManyToMany association
- Removing entities from a ManyToMany association with composite identifier
- Removing entities from a ManyToMany association with composite identifier including a foreign one

When applying a fix for the "_Loading a OneToMany association with composite identifier including a foreign one_" test, the "_Loading a OneToOne association with composite identifier including a foreign one_" test started to produce an error.

This is due to the Proxy object containing a 16 bytes binary string (in stead of the UUID string) for the foreign identifier.

Also the "_Removing entities from a ManyToMany association with composite identifier including a foreign one_" tests keeps failing because there's a 16 bytes binary string (in stead of the UUID string) for the foreign identifier in the Collection.

I have a feeling these last 2 cases are not because of an issue in the Persisters, but because of an issue in the Hydrators. Unfortunately I don't know where to begin looking :(

I could really need some help finishing this up!
Please skip any API in any entities, so that we really just focus on the actual implementation issues: public properties are OK here.