Test against (bad) custom data sources

### What is the problem or limitation you are having?

Currently the testbed tests for the widgets which use data sources are all using the default list and tree sources, which are fairly robust. But they are intended to be used with user-supplied custom data sources as well. While a well-written data source should perform properly, it is likely that developers writing their own data sources will make mistakes. In these cases good feedback about the problem is preferable to a hard crash which may be difficult to interpret.

### Describe the solution you'd like

If there were tests of data sources which are bad in some ways (eg. failing to notify when the data changes, or raising an exception when asked for data) that verify that these are handled gracefully.

Exactly what "gracefully" means isn't entirely clear to me - crashing is OK, for example, as long as there is information provided as part of a traceback or log that can help pin-point what went wrong. The complexity is that a lot of this code is called as callbacks from C/C++, and worst case is that you get a crash at that layer with no diagnostics.

### Describe alternatives you've considered

Not doing anything is an option. It may be difficult to get a consistent behaviour for all backends that is testable.

### Additional context

This came up from discussion in #4081.

Start by reading the testbed tests for widgets that use the default list and tree data sources, then review discussion #4081. Identify bad custom data-source behaviors such as missing change notifications or exceptions during data access, and define diagnostics that can be tested across backends; done means failures provide useful traceback or log information rather than opaque callback crashes.

Written by the indexing model from the issue text.