Listeners behavior discussion

[John Hendrikx]

I've done another test, where I delayed nested event emission (code 
here: 
https://github.com/hjohn/jfx/commit/fe63a4ee2284c0ed440c4521504a3c5db55f631d)

No tests broke.  Basically, the change will queue up at most one nested 
event emission. It will use the historically correct old/new values for 
each emission.

Even though nothing broke, I saw a rather curious practice in 
SpinnerValueFactory.  The value factory has an internal value property 
on which it places restrictions using a change listener which will cap 
the value to a minimum or maximum when its out of range. This value is 
in turn bound to a read only property Spinner#valueProperty.

Depending on where you check the value of the spinner in user code, you 
get different results.  Assuming a spinner in the range of [0, 100] with 
a current value of 99, changing the value to 200 triggers the following 
events when observing Spinner#valueProperty:

99 -> 200
200 -> 100

When you observe Spinner#valueFactoryProperty#valueProperty you instead 
see:

200 -> 100 (send out by a nested emission)
99 -> 100 (send out when the top level emission finishes)

When you apply my change, both these would be the same for both properties:

99 -> 200
200 -> 100

I think its odd in the first place these events are published. When I 
limit a spinner to a certain range, I'd never expect to see out of range 
values published. Instead I'd only expect:

99 -> 100

Still, I think the delayed version sends out more consistent events in 
this case.

--John