Remove the `go_to_diagnostic_searches_at_cursor` setting, as its default
behavior seems to be an acceptable behavior to me, so I'd rather have
that be the default and avoid introducing another setting just to
control this behavior.

As such, with this change, everytime `editor: go to diagnostic` or
`editor: go to previous diagnostic` are used, it'll first attempt to
expand the diagnostic at the current cursor position, in case there's
one, otherwise it'll either navigate to the next or previous diagnostic,
expanding that one instead, respectively.

* Introduce `editor::diagnostics::Editor.activate_diagnostic` which,
  given a diagnostic entry, will update the cursor position and expand
  the respective diagnostic.
* Introduce `editor::diagnostics::Editor::diagnostics_before_cursor` and
  `editor::diagnostics::Editor::diagnostics_after_cursor` to make it
  easier for callers to find that information, as it used to be a
  function/method implemented inside
  `editor::diagnostics::Editor.go_to_diagnostic_impl`.
* Introduce `editor::diagnostics::Editor.go_to_diagnostic_at_cursor`,
  moving that logic outside of
  `editor::diagnostics::Editor.go_to_diagnostic_impl`. With this change,
  the `direction` argument in
  `editor::diagnostics::Editor.go_to_diagnostic_impl` no longer needs to
  be a `Option<Direction>` and can simply be a `Direction`.
* Remove the `go_to_diagnostic_with_severity_start_after_cursor` test as
  it no longer makes sense, seeing as we removed the setting.

The previous changes to how the diagnostic under the cursor was expanded
only if there were not yet any active diagnostics had a small bug where,
if a diagnostic was already expanded but the user navigated to a
different one through regular keyboard or mouse movement, then using
`editor: go to diagnostic` would not activate the diagnostic under the
cursor, but jump to the one after.

The changes in this commit fixes that issue, changing the behavior a
little bit such that, regardless of whether we're going to the next or
previous diagnostic, we always try to first expand the diagnostic under
the cursor, in case there's one and it's not yet active, otherwise we
navigate in the provided direction.

Lastly, a minor change to
`editor::diagnostics::Editor.activate_diagnostics` was made to ensure
that, even when a global diagnostic renderer is not registered, we use
an empty set of blocks and still track the active group as without this
fix, the `go_to_prev_overlapping_diagnostic` test would fail, as we rely
on the active group id in `go_to_diagnostic_at_cursor` in order to
understand if the cursor is already at the active diagnostic.