WIP Cascade entities loaded during flush

[bahusoid]

This change allows to properly flush and cascade entities that were loaded and modified during flush (I know this is not recommended way of doing things but sometime it can be useful)

Fixes #1252

[hazzik]

This is extremely weird use case. I spent too much time trying to understand what's going on.

[bahusoid]

Yeah. I agree test case from #1252 is very weird. But in general this PR covers condition when entity is modified on loading event and this loading happens during flush for whatever reasons (non lazy association or something like that)

In test case it's not even loading it's proxy creation.

[hazzik]

This is what it takes to make the test green (90ea467):

nhibernate-core/src/NHibernate.Test/NHSpecificTest/NH2919/Child.cs

Lines 9 to 13 in 90ea467

	public Child()
	{
	if ( CREATE_WITH_TOY )
	DynamicToy = new Toy();
	}

[hazzik]

The culprit is access="readonly". This so called "feature" should have never been implemented.

[hazzik]

The test becomes green when either:

• DynamicToy is set using the property
• DynamicToy does not have access="readonly"

[bahusoid]

The test becomes green when either:
DynamicToy is set using the property

That's because of stupid logic inside property setter. Yeah test is strange and I should have come up with something more simpler and clear instead of reusing it. But again the issue should be clear: entity is loaded and modified during flush. Cascade changes won't be applied for such entities. If you have some complex checks in interceptor - it's quite possible scenario (I've personally investigated it in some legacy app).

I will try to add some simple test demonstrating this behavior as I agree current test is hard to understand

[bahusoid]

Actually I can't come up with anything that looks sane :) Maybe such scenarios are indeed should be considered too specific to be handled in nhibernate. So feel free to close this PR...

[hazzik]

DynamicToy does not have access="readonly"

This still holds.

[hazzik]

These tests need a sensible asserts at least. They currently do not check anything (except implicit check for TransientObjectException).