Fix many-to-one disabled filters for entity joins

[fredericDelaporte]

fix #3046

[fredericDelaporte]

use-many-to-one="false" is the only change compared to #2549 tests.

[fredericDelaporte]

Little cleanup by the way.

[fredericDelaporte]

I initially though the GetOnCondition implementation may be troublesome in some cases, because it does filter enabledFilters according to their use-many-to-one setting:

nhibernate-core/src/NHibernate/Type/EntityType.cs

Lines 501 to 512 in e99cf43

	public string GetOnCondition(string alias, ISessionFactoryImplementor factory, IDictionary<string, IFilter> enabledFilters)
	{
	if (IsReferenceToPrimaryKey)
	{
	//TODO: this is a bit arbitrary, expose a switch to the user?
	return string.Empty;
	}
	else
	{
	return GetAssociatedJoinable(factory).FilterFragment(alias, FilterHelper.GetEnabledForManyToOne(enabledFilters));
	}
	}

And later here, we take the on clause if it is not empty, instead of computing it with all filters if ForceFilter. It appears this on clause will always be empty in our case, arbitrary joins, because GetOnCondition current implementation always yields that excepted for property-ref associations.

nhibernate-core/src/NHibernate/Type/EntityType.cs

Lines 496 to 499 in e99cf43

	public bool IsReferenceToPrimaryKey
	{
	get { return string.IsNullOrEmpty(uniqueKeyPropertyName); }
	}

So, the current change is enough to fix the trouble. I cannot think of a related test case demonstrating a need to change GetOnCondition. This implementation looks a bit brittle to me, but a patch change is not the place to get things better from that viewpoint, unless we can demonstrate a failing case.

[fredericDelaporte]

I have considered ForceFilter was meant to apply all filters, not just many-to-one enabled filters. But maybe I am wrong and it is here just for discriminator filters and other non session filters related filtering. In such case this change may not be suitable.

ForceFilter is enabled for entity joins. I think entity joins are arbitrary joins and should not respect the many-to-one filter setting, which seems to me about entity association joins. In such case, this fix would be legit.

But if instead we consider the many-to-one filter setting should be taken into account for arbitrary joins, meaning the filters should be disabled on arbitrary joins if that setting is disabled, then we should instead just add a breaking change in the releases note for v5.3.0.