Fix flaky IndexSetupTests on RavenDB

[abparticular]

IndexSetupTests.Indexes_should_be_reset_on_setup (and its sibling paths through UpdateIndex) has been failing intermittently on CI with an unhandled exception from WaitForIndexDefinitionUpdate.

The polling loop already tolerated a plain OperationCanceledException, with a comment noting "we can get this if we query right when the update happens", but that only covered the client-side cancellation shape. In practice, querying GetIndexStatisticsOperation right as RavenDB swaps an index's underlying storage engine during a reset can throw a variety of transient errors, not just that one:

• OperationCanceledException from the read transaction being cancelled as the reset starts
• ObjectDisposedException ("Index persistence for index '...' was already disposed"), from the old engine's index persistence (e.g. Lucene) being torn down once the reset takes over

Both surfaced in real CI failures as Raven.Client.Exceptions.RavenException. RavenDB reconstructs a generic wrapper client-side for server exceptions it doesn't specifically know how to rehydrate, so the original type/message ends up embedded in RavenException.Message rather than as a genuine .InnerException.

WaitForIndexDefinitionUpdate now tolerates up to MaxTransientRavenExceptionRetries (2) consecutive RavenExceptions of any kind before letting one propagate.

A genuinely broken index (or a bug in the test itself) still fails fast with its real exception, rather than being silently retried for the rest of the test's 30s timeout budget.

Also moved RavenDB DeleteDatabase code into the TestHelper since it is only tests that are deleting databases.