Provide a way to prevent GPUI from creating AccessKit adapters, and
enable this in Zed.

This will allow us to test AccessKit support in Zed without rolling it
out more broadly, while we gain confidence in the implementation in
GPUI.

I've also added a log statement

## Motivation (i.e. a mini post-mortem about the #56065 panics)

Merging #56065 caused some nasty panics in nightly. This was caused by a
bug in the logic for selecting a focus node for a `TreeUpdate`.
AccessKit panics when an invalid `TreeUpdate` is provided.

My assumption was that, since Zed uses no a11y APIs, and also that
essentially 0 zed users would have AT apps running, that merging this PR
would have no effect on the behaviour of Zed itself. However, two issues
combined to cause the panics:
- It seems like many people (everyone?) on mac gets the activation
callback called by accesskit_macos. A quick search suggests this might
be due to password managers searching for password fields, but not sure
how true that is.
- The bug in question related to *forgetting to check* whether a node
used a11y APIs, so we *were* pushing non-empty `TreeUpdate`s

As a (probably temporary) defensive measure, I added a function to try
to detect the bad cases and fix them. But it would be lovely if this
could live in AccessKit itself, since it would mean we wouldn't have to
do the check twice (once in GPUI, once in AccessKit). This would also
help prevent drift when updating accesskit versions if new invariants
are added.

We also cannot protect against this with `catch_unwind`, since we use
`panic=abort`. So our only option unfortunately is to temporarily
disable AccessKit until we know our implementation is stable.

Release Notes:

- N/A or Added/Fixed/Improved ...