Workaround for bad ImageList ownership management

[weltkante]

Fixes #3358

Proposed changes

Disable sharing ImageList handles because they are implemented incorrectly and can double-free handles, which will crash if the handle was reused already (#3358). Instead of sharing ImageLists this PR creates an explicit duplicate when assigning an ImageList to the native control, and destroys the previous instance. This guarantees the handle used by the native control is always unique and can be safely destroyed. To avoid leaks all ImageLists are removed when the handle is destroyed.

#3531 is tracking proper implementation of ImageList ownership

For TreeViews the StateImageList is never shareable and it had similar bugs, so the correct solution is also to create unique handles and destroy them. Part of the logic already was there, but it was too eager and destroyed ImageLists it didn't own. By creating unique handles this problem is avoided.

Customer Impact

• ImageLists don't get destroyed prematurely (see Setting ListView.CheckBoxes after ListView.StateImageList destroys imagelist #3531)
• Usage of ImageLists on checkbox-enabled TreeView or ListView controls no longer risks double-free crashes
• Higher memory usage due to duplicating ImageLists

Regression?

• No, the memory corruption and ownership issues were also present in Desktop Framework

Risk

• This changes semantics of how ImageLists are managed, users which send window messages directly to the native control may not be prepared to handle this.

Before

• ImageLists were destroyed while still in use
• ImageLists were destroyed twice (risk of crashing if numeric handle value was reused)

After

• ImageList destruction result is checked in debug builds to verify no double-free happened

Test methodology

• Running the test suite in a debugger and ensure the asserts detected no double-frees

Microsoft Reviewers: Open in CodeFlow

[weltkante]

/cc @JeremyKuhne @RussKie your choice if you want to take this, or if you want to leave tests broken for now and fix ImageList ownership management properly later (#3531). There are obvious downsides to this workaround, using more memory and changing native control configuration (see PR description). I've no strong opinion, I don't think it happens much in practice outside of the unit tests.

[JeremyKuhne]

Thanks for this @weltkante !