Bump Salsa revision manually for non-Salsa updates

[lionel-]

Branched from #1314
Part of #1212

Removes a FIXME that I left for non-Salsa inputs, like console inputs and diagnostics config. These updates manually triggered diagnostics out-of-band, which had the issue that ongoing diagnostics did not get cancelled by a Salsa bump. The concurrent diagnostics could publish out of order, resulting in stale results.

It's actually easy to bump the revision manually, which both cancels in flight diagnostics and ensures ordering. That's because the synthetic write:

• Causes Salsa to trigger cancellation and park the caller until all readers are dropped
• Refreshes diagnostics automatically via the revision check at the end of the main loop.

[DavisVaughan]

Suggested change

	/// advancing the revision synthetically (see `WorldState::bump_revision`).
	/// advancing the revision synthetically (see [`WorldState::bump_revision`]).

if you want to linkify the doc comments

[DavisVaughan]

Suggested change

	// Refresh diagnostics if the configuration changed. The config lives
	// outside Oak so we bump the revision manually.
	if state.config.diagnostics != diagnostics_config {
	tracing::info!("Refreshing diagnostics after configuration changed");
	lsp::main_loop::diagnostics_refresh_all(state);
	state.bump_revision();
	// Refresh diagnostics if the configuration changed. The config lives
	// outside Oak so we bump the revision manually, causing diagnostics
	// to refresh on the next tick.
	if state.config.diagnostics != diagnostics_config {
	tracing::info!("Bumping salsa revision after configuration changed");
	state.bump_revision();

idk, feels more precise to me this way?

[DavisVaughan]

Suggested change

	// to refresh from here. The scopes live outside oak so we bump the revision
	// manually.
	state.bump_revision();
	// to refresh from here. The scopes live outside oak so we bump the revision
	// manually, causing diagnostics to get refreshed on the next tick.
	state.bump_revision();