Fix property-ref on a component's property

[fredericDelaporte]

Fixes #1824

[fredericDelaporte]

GetProperty yields properties of the entity, it does not go inside components for yielding the component property.

[hazzik]

@fredericDelaporte why does it show my name on the tests?

[hazzik]

Looks correct

[hazzik]

@fredericDelaporte can you check if #1214 is related?

[fredericDelaporte]

@fredericDelaporte why does it show my name on the tests?

Because I have cherry-pick from your 4431485, squashed in it bab942a, then renamed the files and added the property triggering the failure and added a non-dynamic component for allowing checking it was also having the trouble.

@fredericDelaporte can you check if #1214 is related?

I tend to think no, but I will check the test case.

Update: the test case (90b9596) fails completely. It looks like some unrelated regression on property ref with many-to-many has happened since the test case was done.

[fredericDelaporte]

#378 (NH v4.1, NH-3480) has broken #1214 case, which hinders me for diagnosing it.

Reverting #378 by keeping only the UseLHSPrimaryKey path here fixes #1214 previously working test.
By the way the UseLHSPrimaryKey path seems to do quite the opposite to what the property means. #378 causes the property-ref on the collection key column to be ignored when generating the insert SQL for the collection, using instead the primary key name of owner.
But for the failing one, the original reported failure is still not there after my partial local reversion of #378, and it looks to me due to some other #378 consequences I have not yet pinpointed (symptom: identifier value of ManyA is put in the many-to-many table instead of the referenced property value).

Update: a commit message has mislead me, mentioning #211 instead of #378 which has replaced it.

[hazzik]

Because I have cherry-pick from your 4431485,

Ok.

Any reasons not to merge yet?

[fredericDelaporte]

I was still investigating #1214. With #378 getting in the way, I have not yet ascertained it was not bound to the case fixed here, although it does still look unlikely to me.

[fredericDelaporte]

#1214 root cause is a mapping error: using a property-ref on a property not flagged as unique. But NHibernate does not detect this error when validating mappings, and do not raise a good error when attempting to resolve an entity by an undeclared unique key.
So #1214 is not related.

Update: flagging the property as unique changes nothing, because that is not what uses NHibernate for enabling lookup by unique key. So it is not an user error in mapping, but a bug in NHibernate which should have flagged IsAlternateUniqueKey when compiling mappings.