[v11] 12. Raise Replace events for collection notifications

[nirinchev]

Description

Fixes #2854

This doesn't technically need v11, but it would have conflicted, so I decided to do it on top of the nullable annotations branch.

TODO

• Changelog entry
• Tests (if applicable)

[coveralls]

Pull Request Test Coverage Report for Build 4513122303

• 11 of 11 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 81.81%

---

Totals
Change from base Build 4513109284:	0%
Covered Lines:	5875
Relevant Lines:	7056

---

💛 - Coveralls

[papafe]

Could we compute the replaced notifications after added and removed so we don't need to raise Reset in case we have added + replaced or removed + replaced?
With replaced the index should be stable, so I suppose it could work?

[nirinchev]

I would like to avoid special-casing this - if you use foo[i] = new Obj(...), you'll get a replaced index. If you do foo.RemoveAt(i); foo.Insert(i, new Obj(...)), I'd be reluctant to translate that into a replacement, although maybe it'll work better with animations.

[papafe]

As you said, in the second case that will be a reset though, so the whole list will be updated unnecessarily. That's annoying especially if the index is out of the visible collection on screen, and there could be some usability issues if the user is currently interacting with the list.
Generally, we should try to avoid raising resets, but that would probably require to make this method much more complex.
We could also keep it as you wrote it now, and create another ticket to spend some time trying to reduce resets to the minimum.