[zbalkan]

Summary

Adds ObjectListView.DeferViewUpdates(), an IDisposable wrapper around the existing Freeze() / Unfreeze() mechanism.

The method allows callers to write:

using (listView.DeferViewUpdates())
{
    // Perform multiple changes while the view is frozen.
}

instead of manually pairing Freeze() and Unfreeze().

Motivation

This does not add a new update mechanism. ObjectListView already supports nested update suppression through Freeze() and Unfreeze().

The main benefit is making that existing API easier to use safely in code paths containing exceptions, early returns, or multiple nested callers. Disposing the returned scope releases only the freeze acquired by that scope.

Existing callers that use balanced Freeze() / Unfreeze() pairs remain fully compatible and do not need to migrate.

The practical value is therefore mostly API ergonomics and exception safety. It does not provide a performance improvement by itself and does not materially change behavior for users who do not use explicit update batching.

Changes

• Added DeferViewUpdates() to ObjectListView.
• Added an idempotent disposable scope which calls Unfreeze() when disposed.
• Preserved the existing freeze nesting semantics.
• Avoided unfreezing controls that are already disposing or disposed.
• Updated the Unreleased changelog entry.

Tests

The regression suite covers:

• deferred rebuilding until scope disposal;
• nested scopes;
• exception-safe scope cleanup;
• idempotent scope disposal;
• disposing the owning control before the scope;
• interoperability with an existing manual Freeze();
• out-of-order disposal of nested scopes;
• DataListView update behavior;
• FastDataListView update behavior.

Compatibility

This is an additive API change.

Existing code such as:

listView.Freeze();
try
{
    // ...
}
finally
{
    listView.Unfreeze();
}

continues to behave as before.

DeferViewUpdates() uses the same underlying freeze counter, so manual and scoped freezes can be nested. Each caller should release only the freeze it acquired.

Limitations

This PR intentionally does not:

• replace or deprecate Freeze() / Unfreeze();
• introduce asynchronous updates;
• add additional coalescing beyond the existing freeze mechanism;
• improve update performance independently of existing batching behavior.

For most consumers this is therefore a convenience API rather than a new capability.